[petsc-dev] --download and spack

[Jed Brown]

"Balay, Satish" <balay at mcs.anl.gov> writes:

> On Sun, 21 Oct 2018, Jed Brown wrote:
>
>> "Balay, Satish" <balay at mcs.anl.gov> writes:
>> 
>> > I don't think spack is really a replacemet for --download-package yet.
>> >
>> > For one - it has some initial setup hump users have to go over. [how
>> > does one specify compilers, and my prebuilt MPI?]
>> 
>> The configuration profile is somewhat clumsy, but lots of facilities do
>> it.  If PETSc were to support using spack for prerequisites, we would
>> probably want PETSc to be able to set it up.
>> 
>> > And then - we would need to update petsc support in spack to be as
>> > externsive wrt externalpackages as we currently have.
>> 
>> There are separate ideas:
>> 
>> * ./configure --download-hypre=spack
>> 
>>   or some similar syntax tells configure to ask Spack how to link to a
>>   suitably-built Hypre and to install it if necessary, resolving any
>>   possible transitive dependencies [1].
>
> I don't think spack is designed to support this model [just install
> one package or a subset of pacakges - per our spec]. For one - it
> doesn't have a configure like interface to pass options from petsc
> configure to spack [for all the checks that petsc configure has
> already done.
>
>> 
>> * spack install petsc+hypre
>> 
>>   as a recommended way for users to install.  An issue with this is that
>>   Spack code runs before anything PETSc works with, and Spack setup
>>   (system compilers, MPI, etc.) can be nontrivial.
>
> This is the recommended mode. And I think its useful for users who don't
> want to deal with petsc directly or petsc interface directly.
>
> [for ex: deal.ii users - who want to install deal.ii - but just want a
> compatible petsc installed automatically].

This is *exactly* the same model as you rejected a paragraph above.
There is no difference whether we are talking about installing
dependencies for PETSc or dependencies for Deal.II.

Also, I think most users don't care whether exactly the same compiler
options are passed to all dependent packages.  They want to link against
a working debug or optimized stack with minimal build time.

>> [1] Having configure churn for a while and then say that --download-zlib
>> or --enable-zlib is required is super lame.
>
> spack automatically figures out and installs tonnes of additional packages. The
> above model gives the choice of user deciding what to do. In case of p4est - it could
> be an optionl dependency instead of mandatory dependency.
>
> I guess optional dependency handling is a bit complex.

It is, but if we're downloading a bunch of packages and zlib is deemed
required, we shouldn't fail.  It's these minutes of babysitting
configure and needing to start over to add non-obvious dependencies that
is infuriating and drives people away from PETSc and/or blocks them from
running their code at new facilities.  (It's a completely different
calculus if I know I can log in, issue a couple simple commands, and be
running in 5-10 minutes versus if I expect to need to babysit and
troubleshoot configuration idiosyncrasies for hours.)

>> > And if you want to build any branch of petsc from spack - it requires
>> > additional configs to spack code [an entry for each petsc branch].
>> >
>> > One feature that petsc configure has - that spack does not yet have
>> > (as far as I know) is 'self.dlib' - which I just used in p4est.py: [Ah
>> > - I see a bug in my code - there should also be a corresponding usage
>> > of 'self.dinclude'].
>> 
>> It is broken encapsulation if this is required for includes or for
>> linking with shared libraries.  Pkg-config and similar systems have
>> Libs.static for such transitive dependencies.  Spack has this
>> information.  Are you saying it breaks when using static libraries?
>
> Currently there is now way to tell spack - build all packages as static. [or shared].
>
>> 
>> P4est is actively maintained and should be fixed if it at fault in this
>> instance.
>> 
>> > And then there is the compiler library detection issue. [ideally spack
>> > should detect this and pass it down to all packages]. Curently some
>> > packages have hacks for this.
>> >
>> > var/spack/repos/builtin/packages/zoltan/package.py:                config_args.append('--with-libs=-lgfortran')
>> > var/spack/repos/builtin/packages/mfem/package.py:            libs += LibraryList(find_system_libraries('libdl'))
>> >
>> > etc..
>> 
>> Have these been reported in the Spack issue tracker?
>
> These issues came up in some PRs or issues. Sorry I don't have references.
>
> Satish