From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:36383) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izapX-0006Et-P7 for guix-patches@gnu.org; Thu, 06 Feb 2020 01:40:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izapW-00052a-G0 for guix-patches@gnu.org; Thu, 06 Feb 2020 01:40:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41059) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izapW-00051u-Bb for guix-patches@gnu.org; Thu, 06 Feb 2020 01:40:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1izapW-00054x-98 for guix-patches@gnu.org; Thu, 06 Feb 2020 01:40:02 -0500 Subject: [bug#39414] [PATCH core-updates 0/2] Clarify search path handling in commencement.scm Resent-Message-ID: From: Jan Nieuwenhuizen References: <20200204125314.27494-1-ludo@gnu.org> Date: Thu, 06 Feb 2020 07:39:00 +0100 In-Reply-To: <20200204125314.27494-1-ludo@gnu.org> ("Ludovic \=\?utf-8\?Q\?Cou\?\= \=\?utf-8\?Q\?rt\=C3\=A8s\=22's\?\= message of "Tue, 4 Feb 2020 13:53:14 +0100") Message-ID: <87wo9043uj.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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 39414@debbugs.gnu.org Ludovic Court=C3=A8s writes: Hello Ludo', > The patch below for current =E2=80=98core-updates=E2=80=99 is an attempt = to clarify > search path handling in commencement.scm by: (Weird, this initial mail got sorted into a new debbugs-submit folder, only found it later) > 1. Having =E2=80=98native-search-paths=E2=80=99 fields only for compile= rs=E2=80=94e.g., > =E2=80=9CC_INCLUDE_PATH=E2=80=9D belongs to the compiler, not to lib= c. > > 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 searc= h 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 coreutil= s=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. > 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 at= 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, janneke= !) 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. 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 ...)? I haven't looked into the consequences. In any case, with patch it has gotten a lot better already, thank you! janneke --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com