Merge branch 'bugfix/iteration-variables' into 'master'
ref:spack/dune-spack\> 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\...
See merge request [spack/dune-spack!21]
[spack/dune-spack!21]: gitlab.dune-project.org/spack/dune-spack/merge_requests/21
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...
Merge branch 'feature/reduce-variants' into 'master'
ref:spack/dune-spack\> 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.
See merge request [spack/dune-spack!20]
[spack/dune-spack!20]: gitlab.dune-project.org/spack/dune-spack/merge_requests/20
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.
Merge branch 'feature/variant-dependencies' into 'master'
ref:spack/dune-spack\> 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. This introduces even more
subtle bugs as more Dune modules are added to the package as any
Dune-module-dependent logic in the package needs to be duplicated for each
Dune module that depends on the module that originally introduced that logic
(yuck!).
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.
See merge request [spack/dune-spack!19]
[spack/dune-spack!19]: gitlab.dune-project.org/spack/dune-spack/merge_requests/19
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.
Merge branch 'feature/dune-testtools' into 'master'
ref:spack/dune-spack\> This module is special as it works with the Dune
virtualenv.
See merge request [spack/dune-spack!11]
[spack/dune-spack!11]: gitlab.dune-project.org/spack/dune-spack/merge_requests/11
Merge branch 'feature/enforce-variants' into 'master'
ref:spack/dune-spack\> In my case, some system libraries still slipped in
though I do not know how exactly.
See merge request [spack/dune-spack!9]
[spack/dune-spack!9]: gitlab.dune-project.org/spack/dune-spack/merge_requests/9
Merge branch 'feature/fix-python-with-multiple-versions' into 'master'
ref:spack/dune-spack\> 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.
This fixes [#8]
See merge request [spack/dune-spack!8]
[#8]: gitlab.dune-project.org/NoneNone/issues/8
[spack/dune-spack!8]: gitlab.dune-project.org/spack/dune-spack/merge_requests/8
Closes#8
Merge branch 'feature/variant-restructuring' into 'master'
ref:spack/dune-spack\> 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.
Sits on top of [!6]
See merge request [spack/dune-spack!7]
[!6]: gitlab.dune-project.org/NoneNone/merge_requests/6
[spack/dune-spack!7]: gitlab.dune-project.org/spack/dune-spack/merge_requests/7
Merge branch 'feature/cleanups' into 'master'
ref:spack/dune-spack\> Regarding coding style and use of Spack functions.
Builds on top of [!5]
See merge request [spack/dune-spack!6]
[!5]: gitlab.dune-project.org/NoneNone/merge_requests/5
[spack/dune-spack!6]: gitlab.dune-project.org/spack/dune-spack/merge_requests/6
Merge branch 'feature/versions-and-refactoring' into 'master'
ref:spack/dune-spack\> This should have been two merge requests really, but by
the time I finished it was much harder to separate the two from each other
than just throw it online\...
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 from upstream in
_get_needed_resources: Instead, it modifies the resource list to include the
transitive closure of Dune module dependencies and then calls the original
implementation.
@gauthier.folzan I would be really interested in your opinion on this.
This fixes [#2].
See merge request [spack/dune-spack!5]
[#2]: gitlab.dune-project.org/NoneNone/issues/2
[spack/dune-spack!5]: gitlab.dune-project.org/spack/dune-spack/merge_requests/5
Closes#2
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.
Dominic Kempf