From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: "Maurice Brémond" <Maurice.Bremond@inria.fr>, 39588@debbugs.gnu.org
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 [thread overview]
Message-ID: <CAJ3okZ1DnP9ZZE2Ovxj_87Akazxw+743ahwTNDN24aBThGB+jg@mail.gmail.com> (raw)
In-Reply-To: <87eeupd3t1.fsf@gnu.org>
Hi Ludo,
On Thu, 20 Feb 2020 at 10:08, Ludovic Courtès <ludo@gnu.org> 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
next prev parent reply other threads:[~2020-02-20 10:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 10:44 [bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpich, python-mpi4py-mpich Maurice Brémond
2020-02-17 17:26 ` Ludovic Courtès
2020-02-17 18:20 ` zimoun
2020-02-20 9:08 ` Ludovic Courtès
2020-02-20 10:23 ` zimoun [this message]
2020-02-21 8:03 ` Ludovic Courtès
2020-02-21 8:40 ` zimoun
2020-02-25 16:41 ` zimoun
2020-10-15 19:50 ` zimoun
2020-10-16 9:32 ` Ludovic Courtès
2020-10-16 11:46 ` zimoun
2020-10-19 13:46 ` Maurice Brémond
2020-10-20 20:55 ` Ludovic Courtès
2020-10-23 9:33 ` Maurice Brémond
2020-10-23 15:26 ` Ludovic Courtès
2020-10-23 17:04 ` Maurice Brémond
2020-11-02 14:02 ` bug#39588: " Ludovic Courtès
2020-10-21 14:43 ` [bug#39588] (off-topic) double time-machine explanations zimoun
2020-10-23 8:41 ` Maurice Brémond
2020-02-18 17:58 ` [bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpich, python-mpi4py-mpich Maurice Brémond
2020-02-18 18:22 ` zimoun
2020-02-19 11:45 ` Maurice Brémond
2020-02-19 12:11 ` zimoun
2020-02-19 13:34 ` zimoun
2020-02-21 9:01 ` Maurice Brémond
2020-02-20 9:38 ` Ludovic Courtès
2020-02-21 8:46 ` Maurice Brémond
2020-02-21 11:32 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ3okZ1DnP9ZZE2Ovxj_87Akazxw+743ahwTNDN24aBThGB+jg@mail.gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=39588@debbugs.gnu.org \
--cc=Maurice.Bremond@inria.fr \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).