unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: zimoun <zimon.toutoune@gmail.com>
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 10:08:10 +0100	[thread overview]
Message-ID: <87eeupd3t1.fsf@gnu.org> (raw)
In-Reply-To: <CAJ3okZ0szPexSebyY4Td+M9Lb06WGHD__Qh+A3qOvL-Ei2efnw@mail.gmail.com> (zimoun's message of "Mon, 17 Feb 2020 19:20:44 +0100")

Hello!

zimoun <zimon.toutoune@gmail.com> skribis:

> On Mon, 17 Feb 2020 at 18:27, Ludovic Courtès <ludo@gnu.org> 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	other threads:[~2020-02-20  9:09 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 [this message]
2020-02-20 10:23       ` zimoun
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=87eeupd3t1.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=39588@debbugs.gnu.org \
    --cc=Maurice.Bremond@inria.fr \
    --cc=zimon.toutoune@gmail.com \
    /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).