"Balay, Satish" <[email protected]> writes: > On Sun, 21 Oct 2018, Jed Brown wrote: > >> "Balay, Satish" <[email protected]> writes: >> >> > On Sun, 21 Oct 2018, Jed Brown wrote: >> > >> >> "Balay, Satish" <[email protected]> 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.
Okay, fair enough. But if it's usable for installing dependencies needed by a typical deal.II user, it should also be usable for installing PETSc's dependencies. >> 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.. I agree it can be irritating, though Spack is reasonably reliable about caching previous builds so it usually isn't starting over from scratch after fixing any particular issue. And I didn't mean that the zlib thing on its own is a reason to use Spack, but that PETSc configure should either return immediately (<5 seconds) if the dependency graph is incomplete and/or try to do what the user surely wants and find a zlib.
