On release 2.6 PDELab had a very old requirement for CMake and didn't allow to install the module properly.
i.e. other modules where not able to resolve its CMake targets correctly. This issue was solved for release 2.7.
Spack's weird overall architecture makes temporary variables in the
package scope really dangerous. In my case, an iteration variable
'module' caused the perl package to fall over...
I really do not see much value in e.g. having a switch to build
without BLAS. Instead, cheap upstream dependencies are always built
and expensive ones have a variant. This reduces variant bloat.
The previous approach had the big downside of bypassing
the specified variants through the specified dependencies
of variants. E.g. dune+pdelab~functions would silently ignore
the ~functions aspect, because +pdelab enforces the installation
of dune-functions.
There is no direct mechanism in Spack to specify such
dependencies in a way that enforces the correct variants
on dependent modules. I have now added conflicts between variants
that reflect the Dune module dependencies. In that case
dune+pdelab~functions would throw an error.
This comes at the cost that a command such as
spack install dune+pdelab
is not possible anymore. Instead the user needs to specify
the dependent modules as well:
spack install dune+pdelab+functions+typetree
Note that in order to remove some burden from users,
I removed the variants for the core modules - they are always
installed.
Actually, make install already installs Python packages,
so there is no need to do it manually in a post-install hook.
Additionally, we set the DUNE_PY_DIR and DUNE_CONTROL_PATH
environment variables, so that the Python bindings work even
in presence of multiple installations.
Some of the variants/dependencies in the prototype were unneeded,
I went through also with a keen eye on keeping the total number
of variants a bit lower. I also added defaults that I consider
useful.
This adds a loop with versions around the resource definitions allowing
for multiple versions of the dune package with the expected behaviour
of dependency forwarding to Dune modules.
Additionally, it avoids the code duplication of _get_needed_resources:
It modifies the resource list to include the transitive closure of
Dune module dependencies and then calls the original implementation.
Zhuo Yang
Dominic Kempf
Santiago Ospina De Los Ríos
Gauthier Folzan