[Dune] Dune and spack

Gauthier Folzan gauthier.folzan at gmail.com
Tue Apr 28 11:59:53 CEST 2020


Hi Dominic,
indeed, I realized that I needed to define the dune variants everywhere
(what I did more or less).
I think defining a common group of variants everywhere is not a so big deal
but the big problem is to propagate these variants across the dependent
modules.
The approach found in some spack packages is to write all possible
combinations but this is cumbersome and I think this is what you mean by
not elegant. Am I right ?
In a first approach, I wanted to have at least a first package to be able
to install dune (at least for me), so what I did is to set every variant to
true to have a consistent set of dune modules but I agree this is not a
solution.
I found some discussions about variant propagation in spack forums but
nothing seems to have been merged in the main branch.
To be sure, don't you have the same problem of flags coherence across
modules using only cmake but compiling one by one the dune modules ?
Regards,
Gauthier

On Wed, Apr 22, 2020 at 11:05 AM Dominic Kempf <dominic.r.kempf at gmail.com>
wrote:

> Hey Gauthier,
>
> sorry for jumping in late.
>
> Christian has it right here, I was looking into Spack as a way of setting
> up our CI and maybe moving towards testing variability in user landscapes
> as well. The main reason I stopped working on it was that the following
> particularity (some people call it a bug) of the Dune CMake build system
> clashes with Spack:
> Each Dune module reruns cmake find scripts for dependencies of all Dune
> modules it depends on instead of importing the full configuration of the
> upstream modules. Due to this behaviour only modules that were built in the
> same environment and with the same flags can be safely used together (as
> their cmake find scripts found the same things).
> For Spack, that means that all variants that you define need to be
> redundantly defined across all modules, and dependencies between those need
> to be specified manually. That is neither elegant nor feasible in
> maintenance.
> The Dune developers have voiced their willingness to abandon this
> behaviour, but a volunteer to do such a tedious, unrewarding work is yet to
> be found.
>
> Best,
> Dominic
>
> On Wed, Apr 1, 2020 at 3:29 PM Gauthier Folzan <gauthier.folzan at gmail.com>
> wrote:
>
>> Hi Christian,
>> here is the link : https://github.com/gauthier12/dune_spack_repo.git
>> It is still work in progress and I am still testing so I don't guarantee
>> anything but it seems to work on ubuntu, centos and archlinux for
>> dune-pyhon with dune-common, dune-geometry, dune-grid, dune-istl and
>> dune-uggrid
>> Once you have spack installed, installing dune is quite simple, just add
>> the repo and install dune
>> spack repo add dune_spack_repo
>> spack install dune-python
>> Cheers
>> Gauthier
>>
>> On Tue, Mar 31, 2020 at 4:46 PM Christian Engwer <
>> christian.engwer at uni-muenster.de> wrote:
>>
>>> Hi Gauthier,
>>>
>>> welcome to Dune,
>>>
>>> > Does someone use spack to compile Dune ? If it can be useful to
>>> someone,
>>> > the spack repo is on github.
>>>
>>> I think nobody is actively using spack for Dune currently, Dominik had
>>> been workin on spack packages... I think his intention was to ease the
>>> CI setup.
>>>
>>> On the other hand, if spack packages are available, it might become
>>> more appealing for other people ;-) Can you post a link to your repo?
>>>
>>> Thanks
>>> Christian
>>>
>> _______________________________________________
>> Dune mailing list
>> Dune at lists.dune-project.org
>> https://lists.dune-project.org/mailman/listinfo/dune
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20200428/52087dac/attachment.htm>


More information about the Dune mailing list