So, the keyword develop should be in the range of @0.99:

It isn't:

(trimmed paths, they're all correct)

'cmake' '[...]/Elemental' '-G' 'Unix Makefiles' '-DCMAKE_INSTALL_PREFIX:PATH=[...]' '-DCMAKE_BUILD_TYPE:STRING=Release' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=FALSE' '-DCMAKE_INSTALL_RPATH:STRING=[...];[...];[...];[...];[...]' '-DCMAKE_PREFIX_PATH:STRING=[...];[...];[...]'

All of the -DHydrogen_* are missing.

Fixing the flake8 now.

That should've fixed the flake8.

I suppose adding or 'develop' would also work. EDIT: see below
I'm not sure why anyone would want to use older versions of hydrogen and not elemental.
EDIT: the point was raised that this should be an explicit "conflicts" with elemental. Need to work out which versions are which, however.

@mcneish1

develop is not in '@:0.84' or '@0.99:', this wasn't working.

develop certainly satisfies @0.99:, we have unit tests for those type of things (version comparison and ranges) in Spack. It must be something else, probably related to the when part.

see http://spack.readthedocs.io/en/latest/packaging_guide.html#version-comparison

@davydden / @adamjstewart :
I'm not really sure what's going on then. I'm going to look into it some more.

It's the or

>>>'@:0.84' or '@0.99:'
'@:0.84'

What is the correct way to specify multiple possibilities in @when?

EDIT: or is there one? I read through the packaging guide and there aren't any examples of this happening.

What is the correct way to specify multiple possibilities in @when?

Can you try: '@:0.84,0.99:'

This looks for versions up to and including 0.84 and versions 0.99 and above.

Can you try: '@:0.84,0.99:'

that should work, i used those in other places, i.e. @1.59.0:1.63,1.65.1,1.67.0:

That did it.

I grepped for ' or ' and ' and ' ('a' and 'b' returns 'b') on the whole package list, these ones look like they have the same issue:
geant4:
if '+cxx14' or '+cxx1y' in spec:
lbann:
@when('@:0.90' or '@0.94:')
symengine:
'ON' if ('+thread_safe' or '+openmp') in spec else 'OFF')
raxml: multiple, e.g.:
if '+mpi' and '+avx' and '+pthreads' in spec:

then
intel-mkl: if sys.platform == 'darwin' and '^mpich' in root: could probably do with some parentheses.

I'll fix lbann in this pr since it's still related to hydrogen, but I don't know enough about the others.

@mcneish1 i think only lbann is wrong, the rest should be ok. I was clearly wrong in this statement.

>>> 'a' or 'b' in ['b']
'a'
>>> 'a' and 'b' in ['b']
True
>>> ('a' or 'b') in ['b']
False
>>> ('a' and 'b') in ['b']
True

I would expect True, False, True, False based on how they're being used in the packages I quoted.

Yeah, I think they're all wrong. Good catch.

This is pending a few edits to elemental and a conflicts or two, but it can merge as-is if @bvanessen wants the builds fixed on our non-gpu systems sooner.

I would like to see the range and conflicts statement go back into the hydrogen package so that it properly excludes earlier builds from the LLNL/elemental repo from using the hydrogen spack package for versions that are out of range.

I'm convinced that's the wrong direction to specify the dependencies. If lbann needs a current version of hydrogen, it seems more correct to put the depends_on('elemental') or the depends_on('hydrogen') in lbann, based off the lbann version being installed.

(We should also delete LLNL/Elemental archived releases before 0.99 as they are no different from elemental/Elemental's)

I am not worried about LBANN using the wrong version of hydrogen, I am worried that someone will try to use the older versions of the LLNL/Elemental.git repo, add the version numbers to a local spack recipe, and not realize that they should be using the Elemental spack package.

Things tested with elemental:

• gcc 6.3
• [email protected] ~shared~hybrid~openmp_blas~python~parmetis~quad~int64~cublas~int64_blas~scalapack~mpfr~c
• [email protected] +shared+hybrid+openmp_blas+python+parmetis+quad+int64+cublas~int64_blas+scalapack+mpfr+c
  • (Note lack of int64_blas. it calls spack/opt/spack/[sys type]/gcc-ar, which is blatantly wrong. Still looking into this)

Things to test:

• intel compilers (at least 17.0.2)
• clang
• xl
• essl/mkl
  • going to find someone with a mac to bug into testing accelerate
• [email protected]

Fixing flake8 now (I'll learn eventually...)

Fixed flake8; updated 1st post TODOs

@bvanessen
I added back elemental@develop and am throwing an InstallError for too-old hydrogen.

• Currently testing XL/intel to make sure the find_libraries calls are okay.
• int64_blas still doesn't work, but it doesn't look like anything I did here is why (and I can't seem to figure out where it's getting openmpi-ar from)
  • Hydrogen's int64_blas works, but it uses openblas directly.

@davydden or @adamjstewart (or someone else?)

Is there a way to handle build@local better than having it at the beginning of the range?

I read through a little of how the when annotations work, tell me if any of this is wrong:
(I'm not sure if versions can be negative, suppose there won't be anything after version 9999)

• @when(x) can only match each x once, for a given function so
  @when('@5'); def cmake_args(): pass
@when('@:6'): def cmake_args(): pass
  is an error
• @when('@:0') matches only local
• @when('@9999:') matches only develop`
• you can chain ranges in when, eg @when('@:0.1,0.2:')
• there is no way to say when-not, eg @when-not('@0.1:0.2') is the same as @when('@:0.1,0.2:'), up to the range boundaries

To me, this indicates that even if I were to say @when('@local'), I wouldn't be able to specify @when('@:x') for any x, since that would conflict with @local, with a similar argument for @develop

Questions

• Am I just missing the way to indicate a not in a when?
• Is there a better way of saying "selecting an earlier version of this package was probably a mistake"?
• It makes sense for @develop to be at the end of the range. It does not make sense for @local to be at the front of the range.
  • What was the justification for this, or do you have a link for that?
  • Would you take a PR fixing @local in every package, then make @local be after every package too?

@mcneish1

handle build@local better than having it at the beginning of the range?

IMO you should simply avoid using local versions. Just give your system-provided package a proper version it corresponds to. @<something> is used for versions, NOT to mark whether a package is provided outside of Spack or built within the Spack. Version comparison is (as expected) indifferent to how the package is built.

Am I just missing the way to indicate a not in a when?

AFAIK it's not possible right now.

It does not make sense for @local to be at the front of the range.

see above, IMO you should simply not use it.

So something like @Local or @ exists below the lowest numeric range and is extremely useful for people that actively develop packages that are built with spack. It is a key part of the spack setup usage.

As for where it exists in the range and with respect to the numeric versions, I think that it is fine to have develop and master be special and any other text string handled differently. I also don't think that we are going make a mass PR to change how all of spack uses @Local, but we can get @tgamblin @becker33 or @scheibelp to chime in on that.

At this point, I would really like to get this PR merged so that it is easier for others of the LBANN team to use the updated Hydrogen version. If the spack dev team wants to rethink all of the version numbering they can do that in a separate PR. Lets please put this one to bed, even if it is not perfect.

So something like @Local or @ exists below the lowest numeric range and is extremely useful for people that actively develop packages that are built with spack. It is a key part of the spack setup usage.

can you elaborate why? I am actively developing packages built with Spack and personally have no use for this.

When we work on developing LBANN I have frequently used spack to setup all of the dependencies for LBANN using spack setup. This allows me to work in my git repo, and the spack setup command gives me a cmake environment that has all of the correct paths to the spack installed dependencies. Quite frankly, I don't know how more people don't use the spack setup command it is great when it works.

When we work on developing LBANN I have frequently used spack to setup all of the dependencies for LBANN using spack setup.

that all I agree and I also build all dependencies via Spack for complicated packages. I am just saying that I don't see where @local is so important to have? Is it a must in spack setup? I must admit I do not use it as it did not work for me last time I tried. Instead my workflow is to do

spack env <spec> bash

together with

cat $(spack location -i <spec>)/.spack/build.out | grep "==> 'cmake'" | sed -e "s/[^ ]*[^ ]/'..\/'/3" | cut -d " " -f2-

for the already built package@develop inside the spack.

When you use spack setup, it can install the package into the spack ecosystem, so it requires a version string that is not develop, master, or a legal version number. It can be any string other than those and local is a common one.

so it requires a version string that is not develop, master, or a legal version number. It can be any string other than those and local is a common one.

hm, so if a package has @develop declared, we could use @develop.local together with #1983 and then version comparison will make sense (it will compare as larger than 1.2.3) as well as spack setup would work?

@tgamblin ping.

Perhaps, I only quickly skimmed the PR.

Okay, I think that addresses all @bvanessen / @adamjstewart 's comments.

• hydrogen@local works, using regular cmake_args
• hydrogen 0:0.98 fails with a concretization error
• lbann still uses 0:0.9, 0.94: / 0.91:0.93, pending the outcome of Sort non-numeric versions higher than numeric versions #8421

Still not sure what's going on with int64_blas, but it appears to work in hydrogen still