<div dir="ltr"><div>Dear Olivier,</div><div><br></div><div>thanks for putting so much work into this.</div><div><br></div><div>I have looked at the Github issue (for reference, it is this one: <a href="https://github.com/spack/spack/pull/391">https://github.com/spack/spack/pull/391</a>).</div><div>The first presented answer is exactly what made me stop working on this, I do not think that is an appropriate</div><div>solution for handling this (exponentially growing) problem.</div><div><br></div><div>Concerning resource directives: I have never heard of them and I wasn't able to quickly find documentation</div><div>on how they are meant to work! Do you have an example how such a thing would look like? Also, is it a mature</div><div>feature of spack? I found myself struggling more than once with half-implemented or abandoned features of</div><div>spack that were not clearly advertised as such (e.g. spack setup) so I am a bit scared of niche features in spack.</div><div><br></div><div>Best,</div><div>Dominic<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 4:31 PM Gauthier Folzan <<a href="mailto:gauthier.folzan@gmail.com">gauthier.folzan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi, <br></div><div></div><div><div></div><div>I asked advices on the spack github and I had an interesting response from Massimiliano Culpo : <br></div><div><p>Maybe a better solution, if it makes sense for Dune, is to treat Dune
 modules as resources. This means having a single "Dune" package with 
multiple <code>resource</code> directives. These resources might be activated by a corresponding variant and Dune should be able to install them on request.</p><p><br></p><p>It was obvious for me to have one spack package by dune module. I didn't think about it but having one unique package makes sense. It ensures options coherence and version coherence between the modules within a package installation. Spack is already multiplying packages installations with different variant, so it's not a problem to have multiple and independent dune installation with different activated modules if needed.</p><p></p><p>What do you think?</p><p>Regards,</p><p>Gauthier<br></p></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 28, 2020 at 1:19 PM Oliver Sander <<a href="mailto:oliver.sander@tu-dresden.de" target="_blank">oliver.sander@tu-dresden.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
as this topic seems to interest quite a number of people, can we not<br>
seize the momentum and actually work on improving Dune towards<br>
the Spack usecase?  I am not a build system expert, but I have yet<br>
to meet somebody who is happy with the current state of module<br>
dependency tracking.  What would a reasonable first step be?<br>
How difficult would it be, e.g., to have Dune modules provide<br>
at least rudimentary config-file packages?<br>
<br>
Best,<br>
Oliver<br>
<br>
On 28.04.20 12:17, Christian Engwer wrote:<br>
> Hi,<br>
> <br>
> this all sound rather nasty. Can we work around this by specifying the<br>
> correct cmake variables from spack and passing them to dependent<br>
> modules?<br>
> <br>
> Christian<br>
> <br>
> On Tue, Apr 28, 2020 at 11:59:53AM +0200, Gauthier Folzan wrote:<br>
>> Hi Dominic,<br>
>> indeed, I realized that I needed to define the dune variants everywhere<br>
>> (what I did more or less).<br>
>> I think defining a common group of variants everywhere is not a so big deal<br>
>> but the big problem is to propagate these variants across the dependent<br>
>> modules.<br>
>> The approach found in some spack packages is to write all possible<br>
>> combinations but this is cumbersome and I think this is what you mean by<br>
>> not elegant. Am I right ?<br>
>> In a first approach, I wanted to have at least a first package to be able<br>
>> to install dune (at least for me), so what I did is to set every variant to<br>
>> true to have a consistent set of dune modules but I agree this is not a<br>
>> solution.<br>
>> I found some discussions about variant propagation in spack forums but<br>
>> nothing seems to have been merged in the main branch.<br>
>> To be sure, don't you have the same problem of flags coherence across<br>
>> modules using only cmake but compiling one by one the dune modules ?<br>
>> Regards,<br>
>> Gauthier<br>
>><br>
>> On Wed, Apr 22, 2020 at 11:05 AM Dominic Kempf <<a href="mailto:dominic.r.kempf@gmail.com" target="_blank">dominic.r.kempf@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> Hey Gauthier,<br>
>>><br>
>>> sorry for jumping in late.<br>
>>><br>
>>> Christian has it right here, I was looking into Spack as a way of setting<br>
>>> up our CI and maybe moving towards testing variability in user landscapes<br>
>>> as well. The main reason I stopped working on it was that the following<br>
>>> particularity (some people call it a bug) of the Dune CMake build system<br>
>>> clashes with Spack:<br>
>>> Each Dune module reruns cmake find scripts for dependencies of all Dune<br>
>>> modules it depends on instead of importing the full configuration of the<br>
>>> upstream modules. Due to this behaviour only modules that were built in the<br>
>>> same environment and with the same flags can be safely used together (as<br>
>>> their cmake find scripts found the same things).<br>
>>> For Spack, that means that all variants that you define need to be<br>
>>> redundantly defined across all modules, and dependencies between those need<br>
>>> to be specified manually. That is neither elegant nor feasible in<br>
>>> maintenance.<br>
>>> The Dune developers have voiced their willingness to abandon this<br>
>>> behaviour, but a volunteer to do such a tedious, unrewarding work is yet to<br>
>>> be found.<br>
>>><br>
>>> Best,<br>
>>> Dominic<br>
>>><br>
>>> On Wed, Apr 1, 2020 at 3:29 PM Gauthier Folzan <<a href="mailto:gauthier.folzan@gmail.com" target="_blank">gauthier.folzan@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> Hi Christian,<br>
>>>> here is the link : <a href="https://github.com/gauthier12/dune_spack_repo.git" rel="noreferrer" target="_blank">https://github.com/gauthier12/dune_spack_repo.git</a><br>
>>>> It is still work in progress and I am still testing so I don't guarantee<br>
>>>> anything but it seems to work on ubuntu, centos and archlinux for<br>
>>>> dune-pyhon with dune-common, dune-geometry, dune-grid, dune-istl and<br>
>>>> dune-uggrid<br>
>>>> Once you have spack installed, installing dune is quite simple, just add<br>
>>>> the repo and install dune<br>
>>>> spack repo add dune_spack_repo<br>
>>>> spack install dune-python<br>
>>>> Cheers<br>
>>>> Gauthier<br>
>>>><br>
>>>> On Tue, Mar 31, 2020 at 4:46 PM Christian Engwer <<br>
>>>> <a href="mailto:christian.engwer@uni-muenster.de" target="_blank">christian.engwer@uni-muenster.de</a>> wrote:<br>
>>>><br>
>>>>> Hi Gauthier,<br>
>>>>><br>
>>>>> welcome to Dune,<br>
>>>>><br>
>>>>>> Does someone use spack to compile Dune ? If it can be useful to<br>
>>>>> someone,<br>
>>>>>> the spack repo is on github.<br>
>>>>><br>
>>>>> I think nobody is actively using spack for Dune currently, Dominik had<br>
>>>>> been workin on spack packages... I think his intention was to ease the<br>
>>>>> CI setup.<br>
>>>>><br>
>>>>> On the other hand, if spack packages are available, it might become<br>
>>>>> more appealing for other people ;-) Can you post a link to your repo?<br>
>>>>><br>
>>>>> Thanks<br>
>>>>> Christian<br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> Dune mailing list<br>
>>>> <a href="mailto:Dune@lists.dune-project.org" target="_blank">Dune@lists.dune-project.org</a><br>
>>>> <a href="https://lists.dune-project.org/mailman/listinfo/dune" rel="noreferrer" target="_blank">https://lists.dune-project.org/mailman/listinfo/dune</a><br>
>>><br>
>>><br>
> <br>
>> _______________________________________________<br>
>> Dune mailing list<br>
>> <a href="mailto:Dune@lists.dune-project.org" target="_blank">Dune@lists.dune-project.org</a><br>
>> <a href="https://lists.dune-project.org/mailman/listinfo/dune" rel="noreferrer" target="_blank">https://lists.dune-project.org/mailman/listinfo/dune</a><br>
> <br>
> <br>
<br>
</blockquote></div>
_______________________________________________<br>
Dune mailing list<br>
<a href="mailto:Dune@lists.dune-project.org" target="_blank">Dune@lists.dune-project.org</a><br>
<a href="https://lists.dune-project.org/mailman/listinfo/dune" rel="noreferrer" target="_blank">https://lists.dune-project.org/mailman/listinfo/dune</a></blockquote></div>