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: > >> > >> > 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.
If certain dependencies change [due to my choice of workarrounds] - it builds another copy of all packages that are affected. > 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. Sure - perhaps there are improvements possible for both the tools.. Satish
