From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:45040) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3l1z-00071j-Jj for guix-patches@gnu.org; Mon, 17 Feb 2020 13:22:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3l1v-0004Yw-Um for guix-patches@gnu.org; Mon, 17 Feb 2020 13:22:07 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:33221) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3l1v-0004Yd-PY for guix-patches@gnu.org; Mon, 17 Feb 2020 13:22:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j3l1u-0000vh-Es for guix-patches@gnu.org; Mon, 17 Feb 2020 13:22: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> In-Reply-To: <87o8tx3z2q.fsf@gnu.org> From: zimoun Date: Mon, 17 Feb 2020 19:20:44 +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, Thank you Maurice for the packages! :-) 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, thoug= h 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 don= =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? Other said, '--with-inputs' will do the job for explicit packages but not the implicit ones. 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/sol= ver Well, for these particular patches, the variants are ok. But we should think about how to ease the variant generation of all the cha= in. Cheers, simon