This enforces conventions that allow for correct handling of
multi-valued variants where specifying no value is an option,
and adds convenience functionality for specifying multi-valued
variants with conflicting sets of values. This also adds a notion
of "feature values" for variants, which are those that are understood
by the build system (e.g. those that would appear as configure
options). In more detail:
* Add documentation on variants to the packaging guide
* Forbid usage of '' or None as a possible variant value, in
particular as a default. To indicate choosing no value, the user
must explicitly define an option like 'none'. Without this,
multi-valued variants with default set to None were not parsable
from the command line (Fixes#6314)
* Add "disjoint_sets" function to support the declaration of
multi-valued variants with conflicting sets of options. For example
a variant "foo" with possible values "a", "b", and "c" where "c"
is exclusive of the other values ("foo=a,b" and "foo=c" are
valid but "foo=a,c" is not).
* Add "any_combination_of" function to support the declaration of
multi-valued variants where it is valid to choose none of the
values. This automatically defines "none" as an option (exclusive
with all other choices); this value does not appear when iterating
over the variant's values, for example in "with_or_without" (which
constructs autotools option strings from variant values).
* The "disjoint_sets" and "any_combination_of" methods return an
object which tracks the possible values. It is also possible to
indicate that some of these values do not correspond to options
understood by the package's build system, such that methods like
"with_or_without" will not define options for those values (this
occurs automatically for "none")
* Add documentation for usage of new functions for specifying
multi-valued variants
- remove the old LGPL license headers from all files in Spack
- add SPDX headers to all files
- core and most packages are (Apache-2.0 OR MIT)
- a very small number of remaining packages are LGPL-2.1-only
* omega-h: fix dependencies
1. Remove Gmodel altogether. Omega_h doesn't
actually call Gmodel for anything, it was
more or less just doing additional unit
testing for Gmodel
2. Make Trilinos off by default. Most codes do
not need the ParameterList interface, and
Kokkos through Trilinos is not well explored
in Spack
3. Use modern CMake style to choose the zlib
dependency
* add 5 most recent versions and git master branch
* add trilinos, gmodel, throw, examples, optimize, symbols,
and warnings variants
* disable XSDK so that Trilinos dependencies are found.
cd /tmp/balay/spack-stage/spack-stage-joxtpr/omega_h-9.13.4/spack-build/src && /home/balay/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/openmpi-3.1.0-7ws4tgx4z3o
ru5g5skjrxs5sobpeiyef/bin/mpic++ -Domega_h_EXPORTS -I/home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src -I/tmp/bala
y/spack-stage/spack-stage-joxtpr/omega_h-9.13.4/spack-build/src -I/home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/tpl
-I/home/balay/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/zlib-1.2.11-5nus6knzumx4ik2yl44jxtgtsl7d54xb/include -O2 -g -DNDEBUG -fPIC -o CMakeFiles/omega_h.di
r/Omega_h_map.cpp.o -c /home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src/Omega_h_map.cpp
In file included from /usr/include/c++/5/chrono:35:0,
from /home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src/Omega_h_timer.hpp:4,
from /home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src/Omega_h_timer.cpp:1:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^
