[petsc-dev] --download and spack

[Balay, Satish]

On Sun, 21 Oct 2018, Jed Brown wrote:

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

Not really. My initial claim was 'spack was not yet a replacement for --download-package' option in PETSc. I don't think deal has this feature.

Satish

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

In my case - I have spack running for 4-6h - and then I get an error -
and then I have to figureout how to work arround them - and restart
builds. Different tools have different error cases..

Satish

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