Skip to content

libSplash: spack dependency bug fixed (other still persists)#1727

Closed
ax3l wants to merge 2 commits intospack:developfrom
ax3l:topic-updateSplashPngDev
Closed

libSplash: spack dependency bug fixed (other still persists)#1727
ax3l wants to merge 2 commits intospack:developfrom
ax3l:topic-updateSplashPngDev

Conversation

@ax3l
Copy link
Copy Markdown
Member

@ax3l ax3l commented Sep 4, 2016

the spack-internal dependency resolution bug mentioned in
#1667 (comment)

seems to be fixed now, and is even causing a bug when not rewritten
#1667 (comment)

This fixes it.

  • use any version of hdf5 if no mpi is requested
  • enforce "parallel" version of hdf5 if mpi is requested

Minor: Also adds missing develop versions to libSplash and PNGwriter in the second commit. (I know, I know...)

ccing @adamjstewart

ax3l added 2 commits September 5, 2016 01:02
the dependency bug mentioned in
    spack#1667 (comment)

seems to be fixed now, and is even causing a bug when not rewritten
    spack#1667 (comment)

This fixes it.

- use any version of hdf5 if no mpi is requested
- enfore "parallel" version of hdf5 if mpi is requested
@ax3l
Copy link
Copy Markdown
Member Author

ax3l commented Sep 4, 2016

warning, install problems seems to be fixed but running

$ spack spec libsplash ^[email protected]

Input spec
------------------------------
  libsplash
      ^[email protected]

Normalized
------------------------------
==> Error: libsplash does not depend on hdf5

still complains.

@ax3l ax3l changed the title Topic update splash png dev libSplash: spack dependency bug fixed (other still persists) Sep 4, 2016
@adamjstewart
Copy link
Copy Markdown
Member

Read through all comments and commits in #1553. That should explain what is causing the problem and a decent solution to it. My solution isn't perfect, but I think it provides the least headaches.

@ax3l
Copy link
Copy Markdown
Member Author

ax3l commented Sep 5, 2016

all right, will wait on the decision there. a hdf5+mpi default might auto-fix it for me.

the normalization process still looks a bit uneasy to me if we have to introduce conventions like "all need to default to +mpi" to get around it. (independent of the fact that I like an all +mpi default, but this won't be the only dependency triggering such issues.)

@adamjstewart
Copy link
Copy Markdown
Member

I agree. At some point we need to tackle variant forwarding. That is, if I specify netcdf+mpi, that means I want the mpi variant to be enabled for netcdf and all of its dependencies, not just netcdf. But for now, this is the best we can do.

@ax3l
Copy link
Copy Markdown
Member Author

ax3l commented Sep 5, 2016

Kind of. But I can also think of software that can be compiled with a +mpi variant but that will only depend on serial hdf5 for posix style i/o (would still compile successfully against hdf5+mpi but does not require it).

the point is: if a dependency hdf5+mpi is set in a package, this should be honoured. And then again the exact dependencies that a build of hdf5+mpi triggers.

we should not rely on that +mpi means the same on all packages.

@ax3l
Copy link
Copy Markdown
Member Author

ax3l commented Sep 12, 2016

@adamjstewart since #1553 is now merged I removed the first commit locally and tried again.

Interestingly, running spack spec is still weird, see this output: (in libSplash +mpi is also the default):

# with defaults: fails
$ spack spec libsplash
Input spec
------------------------------
  libsplash

Normalized
------------------------------
  libsplash
      ^cmake
      ^[email protected]:
          ^zlib

Concretized
------------------------------
==> Error: Invalid spec: '[email protected]%[email protected]+cxx~debug+fortran~mpi+shared~szip~threadsafe arch=linux-debian8-x86_64'. Package hdf5 requires variant +mpi, but spec asked for ~mpi
# with explicit +mpi: ok
$ spack spec libsplash+mpi
Input spec
------------------------------
  libsplash+mpi

Normalized
------------------------------
  libsplash+mpi
      ^cmake
      ^[email protected]:+mpi
          ^mpi
          ^zlib

Concretized
------------------------------
  [email protected]%[email protected]+mpi [...]
# with explicit ~mpi: ok
$ spack spec libsplash~mpi                                                                                                                      (topic-updateSplashPngDev $<>)
Input spec
------------------------------
  libsplash~mpi

Normalized
------------------------------
  libsplash~mpi
      ^cmake
      ^[email protected]:
          ^zlib

Concretized
------------------------------
  [email protected]%[email protected]~mpi [...]

@ax3l
Copy link
Copy Markdown
Member Author

ax3l commented Sep 12, 2016

ah no I am wrong, I rebased against my local branch and not the remote one. seems to work now!

@ax3l
Copy link
Copy Markdown
Member Author

ax3l commented Sep 12, 2016

will open a new PR with the develop versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants