"Balay, Satish" <ba...@mcs.anl.gov> writes: > On Sun, 21 Oct 2018, Jed Brown wrote: > >> "Balay, Satish" <ba...@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