[petsc-dev] --download and spack

[Jed Brown]

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

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



[1] Having configure churn for a while and then say that --download-zlib
or --enable-zlib is required is super lame.

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

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?