@davydden @adamjstewart @alalazo @tgamblin
This is a continuation of #2380. It's in a new thread because the proposal now goes far beyond documentation. The idea would be to Create a dummy package (call it spack for now) with a multi-valued variant (#2386; call it library-type for now taking enum values shared and static). Then make the base class Package depends_on('spack') (#2466) by default. This will have the following effects:
-
Packages should look at spec['spack'].library_type to figure out whether they should either
a) build shared libs (or static libs with -fPIC-or-equivalent)
b) build static libs
-
Users can set up all of Spack for either shared or static mode my making an entry for spack/build_type in packages.yaml. Alternately, they can write ^spack@build-type=xxx directly on the command line.
This proposal solves a serious usability problem of all our other shared vs static proposals: that users will have to put +shared or +static all over their builds and specs --- but ONLY for packages that build binaries. It would have worked out fine for most users, but been a royal PITA for Cray users.
We can do other "universal variants" this way as well. It is much cleaner than trying to forward variants from the top of the DAG. (Or we can attach less-than-universal variants to dummy packages that are only depended on by SOME packages.)
@davydden @adamjstewart @alalazo @tgamblin
This is a continuation of #2380. It's in a new thread because the proposal now goes far beyond documentation. The idea would be to Create a dummy package (call it
spackfor now) with a multi-valued variant (#2386; call itlibrary-typefor now taking enum valuessharedandstatic). Then make the base classPackagedepends_on('spack')(#2466) by default. This will have the following effects:Packages should look at
spec['spack'].library_typeto figure out whether they should eithera) build shared libs (or static libs with
-fPIC-or-equivalent)b) build static libs
Users can set up all of Spack for either shared or static mode my making an entry for
spack/build_typeinpackages.yaml. Alternately, they can write^spack@build-type=xxxdirectly on the command line.This proposal solves a serious usability problem of all our other
sharedvsstaticproposals: that users will have to put+sharedor+staticall over their builds and specs --- but ONLY for packages that build binaries. It would have worked out fine for most users, but been a royal PITA for Cray users.We can do other "universal variants" this way as well. It is much cleaner than trying to forward variants from the top of the DAG. (Or we can attach less-than-universal variants to dummy packages that are only depended on by SOME packages.)