From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:60259) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4izz-0002tR-La for guix-patches@gnu.org; Thu, 20 Feb 2020 05:24:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4izy-0003Dg-GY for guix-patches@gnu.org; Thu, 20 Feb 2020 05:24:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:37905) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4izy-0003DT-DH for guix-patches@gnu.org; Thu, 20 Feb 2020 05:24:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4izy-0008BN-8I for guix-patches@gnu.org; Thu, 20 Feb 2020 05:24:02 -0500 Subject: [bug#39588] gnu: Add mpich, scalapack-mpich, mumps-mpich, pt-scotch-mpich, python-mpi4py-mpich Resent-Message-ID: MIME-Version: 1.0 References: <87blq2rclk.fsf@inria.fr> <87o8tx3z2q.fsf@gnu.org> <87eeupd3t1.fsf@gnu.org> In-Reply-To: <87eeupd3t1.fsf@gnu.org> From: zimoun Date: Thu, 20 Feb 2020 11:23:00 +0100 Message-ID: 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Maurice =?UTF-8?Q?Br=C3=A9mond?= , 39588@debbugs.gnu.org Hi Ludo, On Thu, 20 Feb 2020 at 10:08, Ludovic Court=C3=A8s wrote: > > 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. 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=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.) 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 =E2=80=98package-input-rewriting=E2=80= =99 that could > help: we could define a =E2=80=98package-with-mpich=E2=80=99 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