[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#39862] [PATCH 0/4] update Dune finite element packages

From: Felix Gruber
Subject: [bug#39862] [PATCH 0/4] update Dune finite element packages
Date: Mon, 2 Mar 2020 22:56:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

Hi Simon,

Thank you for your feedback.

On 3/2/20 3:53 PM, zimoun wrote:
> On Sun, 1 Mar 2020 at 21:07, Felix Gruber <address@hidden> wrote:
>> BTW, some other packages exist in variants with and without OpenMPI,
>> e.g. the dealii and dealii-openmpi packages. Do you think that it would
>> be useful to provide similar variants for the dune-* packages, which
>> could also be built without OpenMPI?
> As an end-user, I prefer regular packages 'dune-*' without the input
> 'openmpi' and so with the related tests disabled and then their
> variants; say 'dune-*-openmpi' with the input 'openmpi' correctly
> setup-ed, as in your patch.

Cool, I'll create an additional patch which splits all the dune packages
in those two variants. Still struggling a bit with guile to replace all
the dune-* packages with dune-*-openmpi in an inputs list without copy
pasting the whole list and changing the packages manually.

>> I've checked that all Dune packages still build after my changes (there
>> don't seem to be any other packages that depend on the dune-* packages).
>> Those builds were done using the updated suitesparse package that I've
>> submitted in bug #39839.
> Usually, 'guix refresh -l' lists the packages that would need to be
> rebuilt when upgrading a particular one.

A `guix refresh -l dune-common` only gives me three other dune-*
packages that would result in rebuilding 10 packages overall. Since
dune-common is in the input of all the other dune-* packages, I think
that tells me that there are no non-dune packages that depend on any
dune-* package.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]