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: zimoun
Subject: [bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpich, python-mpi4py-mpich
Date: Thu, 20 Feb 2020 11:23:00 +0100

Hi Ludo,

On Thu, 20 Feb 2020 at 10:08, Ludovic Courtès <address@hidden> wrote:

> > Other said, '--with-inputs' will do the job for explicit packages but
> > not the implicit ones.
>
> Right, ‘--with-input’ could be “good enough”.

About openmpi->mpich, I am not sure it will work because of:

--8<---------------cut here---------------start------------->8---
#:phases (modify-phases %standard-phases
                  (add-before 'check 'mpi-setup
            ,%openmpi-setup))
--8<---------------cut here---------------end--------------->8---




> > 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.)

I agree. Need more thoughts. :-)


> > 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.

> > 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.

Yes. 'with-python2' and 'with-ocaml4.07' rewrite the build-system
(implicit inputs) and 'package-with-mpich' rewrites packages
('package-input-rewritting' so explicit ones) more tweak some
variables (environment and/or flags).
Sounds good. :-)


All the best,
simon





reply via email to

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