guix-patches
[Top][All Lists]
Advanced

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

[bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpic


From: Ludovic Courtès
Subject: [bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpich, python-mpi4py-mpich
Date: Thu, 20 Feb 2020 10:08:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello!

zimoun <address@hidden> skribis:

> On Mon, 17 Feb 2020 at 18:27, Ludovic Courtès <address@hidden> wrote:
>
>> As for the “-mpich” packages: they look good to me, though I’m not
>> entirely sure whether we should create “-mpich” variants for each of
>> them.  Ideally ‘--with-inputs’ would be enough, but I don’t know.  At
>> the same time, those variants don’t cost us much, so if they’re useful,
>> why not.
>
> Is it not related to "package parameters" or the discussion we had
> about rebuilding everything with another compiler?

There’s definitely a connection.

> Other said, '--with-inputs' will do the job for explicit packages but
> not the implicit ones.

Right, ‘--with-input’ could be “good enough”.

> One easy move should to generalize -- if possible -- what is done in
> 'with-python2' or 'with-ocaml4.07'. But I am not convinced it is easy
> because it is clearly dependant on the build system.
>
> On the other hand, I gave a look at spack (after the discussion at
> FOSDEM) and how they do. The WIP branch [1] about the solver is
> interesting: possibly catch incompatibilities earlier using solver
> (SAT or other) and specifications. But I am not convinced neither it
> is the way to go because it adds a lot of complexity for a gain that
> could be discussed. ;-)
>
>
> [1] https://github.com/spack/spack/tree/features/solver/lib/spack/spack/solver

I have yet to look more closely into this.  However, overall, while I
agree that some flexibility is welcome and actually needed, I’m
skeptical about the goal of potentially allowing for any combination, at
the expense of QA (the solver can check for incompatible options,
provided option compatibility is well specified, but it cannot check
whether something will run or even build at all.)

> Well, for these particular patches, the variants are ok.
> But we should think about how to ease the variant generation of all the chain.

Well again there are things like ‘package-input-rewriting’ that could
help: we could define a ‘package-with-mpich’ procedure.

Thanks,
Ludo’.





reply via email to

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