From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:50540) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4hpP-0007vm-8h for guix-patches@gnu.org; Thu, 20 Feb 2020 04:09:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4hpN-0001Pw-T6 for guix-patches@gnu.org; Thu, 20 Feb 2020 04:09:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:37861) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4hpN-0001Ps-Pj for guix-patches@gnu.org; Thu, 20 Feb 2020 04:09:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4hpN-0004Np-LN for guix-patches@gnu.org; Thu, 20 Feb 2020 04:09:01 -0500 Subject: [bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpich, python-mpi4py-mpich Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87blq2rclk.fsf@inria.fr> <87o8tx3z2q.fsf@gnu.org> Date: Thu, 20 Feb 2020 10:08:10 +0100 In-Reply-To: (zimoun's message of "Mon, 17 Feb 2020 19:20:44 +0100") Message-ID: <87eeupd3t1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: zimoun Cc: Maurice =?UTF-8?Q?Br=C3=A9mond?= , 39588@debbugs.gnu.org Hello! zimoun skribis: > On Mon, 17 Feb 2020 at 18:27, Ludovic Court=C3=A8s wrote: > >> As for the =E2=80=9C-mpich=E2=80=9D packages: they look good to me, thou= gh I=E2=80=99m not >> entirely sure whether we should create =E2=80=9C-mpich=E2=80=9D variants= for each of >> them. Ideally =E2=80=98--with-inputs=E2=80=99 would be enough, but I do= n=E2=80=99t know. At >> the same time, those variants don=E2=80=99t cost us much, so if they=E2= =80=99re useful, >> why not. > > Is it not related to "package parameters" or the discussion we had > about rebuilding everything with another compiler? There=E2=80=99s definitely a connection. > Other said, '--with-inputs' will do the job for explicit packages but > not the implicit ones. Right, =E2=80=98--with-input=E2=80=99 could be =E2=80=9Cgood enough=E2=80= =9D. > 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/s= olver I have yet to look more closely into this. However, overall, while I agree that some flexibility is welcome and actually needed, I=E2=80=99m 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 c= hain. Well again there are things like =E2=80=98package-input-rewriting=E2=80=99 = that could help: we could define a =E2=80=98package-with-mpich=E2=80=99 procedure. Thanks, Ludo=E2=80=99.