Spack and C++ Standards

[Morgan, Ben]

Hi all,

A *very* dumb Spack question, which I’m sure has been covered but cannot track it down for the life of me…

When writing a package.py for a C++ package that depends on another C++ package, is there an easy 

way to ensure consistency of standards? In upstream spack, the “cxxstd” variant appears semi-standard, or at

least the easiest way to specify an enumerated value:

https://github.com/spack/spack/search?q=cxxstd&unscoped_q=cxxstd

What I naively thought I could do in a package.py would then be something like:

variant(‘cxxstd’, default=’11’, values=(’11’,’14’,’17’), multi=False)

depends_on(‘bo...@1.63: cxxstd=VALUEOFABOVEVARIANT’)

… but I can’t find any way to use the value of the variant in the spec of the depends_on as self/self.spec doesn’t exist

at this point…

Am I missing something or is there a better way to do this through packages.yaml or similar?

I know I can set default variants in that, but what about if I want to have, say, one stack with gcc7+cxx14,

and another gcc8+cxx17?

Thanks,

Ben.

-- 
==================
Dr. Ben Morgan
Senior Research Fellow
Department of Physics
University of Warwick
Coventry CV4 7AL
==================

[Patrick E Gartung]

Hi Ben,

 

The only way I have found of enforcing cxxstd for all packages is to add a line to packages.yaml which applies variants to all packages that have the corresponding option. For example:

 

packages:

  all:

    variants: [cxxstd=17, +python, + shared]

 

I have been looking at environments to preserve the concretization of packages. This can be used when installing to ensure that you get the same hashes for what has been built, a release for example. The environments directory makes a copy of all package.py files used in the concretization, a spec.yaml file with all specs explicitly added to an environment, and a spec.lock file that contains the concretized hashes. You can then install a prebuilt release with

  spack (-e env name, -D env directory) install

This should check mirror for prebuilt packages with the same hashes as the concretized environment.

 

This all depends on using a clone of the exact packages.yaml, config.yaml, repos.yaml, package.py files that were used to generate the builds used in the buildcache generation. Pretty fragile…

 

Patrick

--
You received this message because you are subscribed to the Google Groups "HSF Build and Packaging Tools Discussion Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hsf-packaging-...@googlegroups.com.
To post to this group, send email to hsf-pack...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hsf-packaging-wg/F7525B48-50AE-494A-B3EF-99AC4E0BD6AC%40warwick.ac.uk.
For more options, visit https://groups.google.com/d/optout.

[Christopher H Green]

Hi,

I made pretty much this same enquiry of the Spack groups a while ago, and the answer was that if you're going to ensure consistency from inside the recipe, the only way to do it is with a slew of:

depends_on('boost cxxstd=11' when='cxxstd=11')
depends_on('boost cxxstd=14' when='cxxstd=14')
depends_on('boost cxxstd=17' when='cxxstd=17')

for every package that requires it.

Its a pain. For the MVP we did this on the install line, essentially, instead of cluttering up all the recipes. One can also specify the value of (say) cxxstd in packages.yaml, but obviously that only works for one combination.

Sorry,

Chris.

[Patrick E Gartung]

Hi Ben,

 

You can also specify package level version and variant preferences in packages.yaml, for example

 

  all:

    compiler: [g...@7.3.0]

    providers:

      pkgconfig: [pkg-config]

      blas: [netlib-lapack]

      lapack: [netlib-lapack]

    variants: ['cxxstd=17']

  root:

    version: [6.12.06]

  boost:

    version: [1.68.0]

  python:

    version: [2.7.15]

    variants: ['+dbm','~optimizations','+pic','+pythoncmd','+shared','~tk', '~ucs4']

 

Note: you have to add global variants to package variants. Package level variants apparently overwrite global variants.

 

Spack does allow you to specify a config directory to use with ‘spack -c dirname’ so you could control different build standards using different config directories.

 

Patrick

[Morgan, Ben]

Hi Patrick, Chris,

That’s very helpful, thanks!

I’ll try the “cxxstd” plus packages.yaml approach as that should get me up to speed, and

is pretty close to what I’ve done with Homebrew in the past.

Patrick, thanks for the heads up on environments, I’ll take a look once I’ve got the above working!

Cheers,

Ben.