[petsc-dev] --download and spack

[Balay, Satish]

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].

> [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.

> 
> > 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