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