From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:54199) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izi7T-0005Jo-Gr for guix-patches@gnu.org; Thu, 06 Feb 2020 09:27:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izi7S-0000JM-D8 for guix-patches@gnu.org; Thu, 06 Feb 2020 09:27:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41218) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izi7S-0000ID-7v for guix-patches@gnu.org; Thu, 06 Feb 2020 09:27:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1izi7S-0003BE-4H for guix-patches@gnu.org; Thu, 06 Feb 2020 09:27:02 -0500 Subject: [bug#39414] [PATCH core-updates 0/2] Clarify search path handling in commencement.scm Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20200204125314.27494-1-ludo@gnu.org> <87wo9043uj.fsf@gnu.org> Date: Thu, 06 Feb 2020 15:25:58 +0100 In-Reply-To: <87wo9043uj.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Thu, 06 Feb 2020 07:39:00 +0100") Message-ID: <87r1z77pxl.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: Jan Nieuwenhuizen Cc: 39414@debbugs.gnu.org Jan Nieuwenhuizen skribis: >> 1. Having =E2=80=98native-search-paths=E2=80=99 fields only for compil= ers=E2=80=94e.g., >> =E2=80=9CC_INCLUDE_PATH=E2=80=9D belongs to the compiler, not to li= bc. >> >> 2. Avoiding phases that manually fiddle with search path >> environment variables: normally, this is handled automatically >> by the =E2=80=98set-paths=E2=80=99 phase based on the declared sear= ch paths, >> so manual fiddling should be a last resort and it should be >> well commented so we remember why it=E2=80=99s there. >> >> This is an attempt to reduce complexity and keep things declarative >> as much as possible. I=E2=80=99ve tested it on top of >> 46312064de8ae0cca531fddbc4b5ec8421e5d866 and =E2=80=9Cguix build coreuti= ls=E2=80=9D >> succeeds. > > Very nice, thank you. I was happy to get it to build and did not > imagine all this fiddling could actually be workarounds that could > (should!) all be removed. Not only will this help readability and > maintenance, it will make porting this to other distributions (NixOS) a > lot easier too. Yes, I hope so! >> There=E2=80=99s another pattern that I found hard to follow that has to = do >> with the reuse of build phases. >> >> For example, there=E2=80=99s a build phase named =E2=80=98setenv=E2=80= =99 (perhaps we should >> find a more descriptive name :-)) in the various GCCs that is reused >> or replaced; when looking at a specific package, it=E2=80=99s difficult = to >> see which phases it really runs because this particular phase is >> inherited and modified on several layers. If I can make time for it, >> I=E2=80=99ll see if I can come up with a proposal to clarify this, but a= t any >> rate, it=E2=80=99s probably something to keep in mind for future changes. >> >> Thoughts? (I=E2=80=99m particularly interested in your feedback, jannek= e!) > > Yes, I agree. A first step could be to use better names and possibly > split it up into serveral stages: set-configure-shells, set-cc-paths? > > Doing this will probably only need overriding the set-cc-paths. I'm not > sure how to make the inherit+replace issue more obvious but it has > been biting me and annoying me too. Yes, I=E2=80=99m not sure exactly how to do it. > Maybe when we get into this replace trickery it is better to not reuse > parent's stages at all > >> (arguments >> (substitute-keyword-arguments (package-arguments gcc-core-mesboot) > > but fully rewrite (arguments ...)? Yes, either that or always inherit from the same package=E2=80=94e.g., alwa= ys inherit from =E2=80=98gcc=E2=80=99 instead of inheriting from =E2=80=98gcc-= mesboot1=E2=80=99, which inherits from =E2=80=98gcc-mesboot0=E2=80=99, and so on. That way one does= n=E2=80=99t have to walk the inheritance chain to understand what the phases are. Another option is to also make the interesting phases generic enough that we don=E2=80=99t have to modify them in package variants. We=E2=80=99ll see! Ludo=E2=80=99.