From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:39792) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igw3D-00008u-Dl for guix-patches@gnu.org; Mon, 16 Dec 2019 14:29:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1igw3C-0006tn-1q for guix-patches@gnu.org; Mon, 16 Dec 2019 14:29:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:34408) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1igw3B-0006tY-UH for guix-patches@gnu.org; Mon, 16 Dec 2019 14:29:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1igw3B-00018Z-QU for guix-patches@gnu.org; Mon, 16 Dec 2019 14:29:01 -0500 Subject: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Resent-Message-ID: From: Jan Nieuwenhuizen References: <87tv6qoank.fsf@gnu.org> <87sgm4m9fu.fsf@gnu.org> <87v9r0arni.fsf@gnu.org> <87y2vqdjwz.fsf@gnu.org> <87y2viyb2a.fsf@gnu.org> <87o8w9s284.fsf@gnu.org> Date: Mon, 16 Dec 2019 20:28:02 +0100 In-Reply-To: <87o8w9s284.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 15 Dec 2019 22:33:47 +0100") Message-ID: <878sncm5od.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: Timothy Sample , 38390@debbugs.gnu.org Ludovic Court=C3=A8s writes: Hi! >> I have just hard-reset wip-bootstrap for the next iteration! > > Yay! and I did it again. > Awesome. > > BTW, I=E2=80=99d suggest this for clarity: > + (file-name "lalr.upstream.scm") Ah, yes. Added. >>> * look at possibility/cost to avoid updating the mescc-tools and mes >>> bootstrap binaries >> >> This proved possible (dare I say feasible?). What was needed is >> >> - allow mescc (0.21+) to work with old mescc-tools 0.5.2 >> - add %bootstrap-mes-rewired, to remove MesCC from mes-0.19 and >> enable it to run 0.21+ MesCC >> >> %bootstrap-mes-rewired uses this hack >> ;; MesCC from mes-0.21 >> (set! %moduledir (string-append prefix \"/mes/module/\")) >> >> ;; A fixed map, from mes-0.21 >> (define (map f h . t) > > =E2=80=98caddr=E2=80=99, loooove it! ;-) > > It seems to me that mescc.scm in 0.21 only use the two-argument =E2=80=98= map=E2=80=99, > no? In that case I guess we could go with a two-argument, fixed-arity > version that would have fewer cdadrs caddrs and caadrs? Just sayin=E2=80= =99. > :-) Ah yes...well almost. MesCC uses map3; so I cut only map4. >> On a related note, should mescc 0.21 include some kind of `hook' make >> this kind of change easier to make? > > Good question! During the summit, Vagrant (I think?) asked whether Mes > and MesCC should be separated. I think in this case it would have been > beneficial to have them distributed separately, no? It might be worth > looking at which parts change frequently to determine what to keep as > part of the =E2=80=98mes=E2=80=99 package itself. > > Thoughts? I've been "struggling" with this question a bit myself. In this particular instance it would not have helped much, since map was broken and I would not have wanted to add a fix for that in mescc. It would have helped switching to the newer mescc. Keeping them in one archive for now is a bit less work for me I think; it saves me managing another dependency. Possibly until mes can boot guile modules. Until mes can do that, mes needs to come with a "shadow *.mes" tree for module inclusion, like it has for Nyacc too. That's less than great, but works... I am open to other perspectives, though. >>> * look into awkward combined bash+gash dependency of glibc-mesboot0 >> >> Haven't addressed this. I quickly looked with Ludo at this, not really >> into it though. WYDT? > > Hmm, dunno. I can take a look later. Okay, great. This issue still remains. I will try to create a bug report for Gash, I think Gash hangs while running configure, while bash-mesboot* have trouble running make-syscalls.sh correctly. I just realise that the mixture of bash/gawk/sed here is possibly one of the things that was replaced by Python. Bootstrapping-wise that seemed like a very bad idea, but I may be starting to see the sanity in such a choice. It would be great if it were Guile, though, or else if Guile could run this Python. > Another thing we discussed was the growth of the dependency graph: > > $ ./pre-inst-env guix graph -e '(@@ (gnu packages commencement) coreutils= -final)' | grep 'label =3D' | wc -l > 177 > $ guix graph -e '(@@ (gnu packages commencement) coreutils-final)' | grep= 'label =3D' | wc -l > 76 > > Clearly we=E2=80=99re adding way more nodes than we mean to. > > For example, you can remove the call to =E2=80=98package-with-bootstrap-g= uile=E2=80=99 > for =E2=80=98bash-mesboot=E2=80=99 (down to 153 nodes) and the one for > =E2=80=98gcc-core-mesboot1=E2=80=99 (down to 121) and the one for =E2=80= =98binutils-mesboot=E2=80=99 > (down to 87), and I think at this point we=E2=80=99re done and the graph = has a > lovely shape. :-) Oh, thank you! Incorporated those changes and verified I got the 87 nodes too. > Also, you can leave out calls to =E2=80=98bootstrap-origin=E2=80=99 for o= rigins without > a snippet and without patches (it=E2=80=99s purely stylistic though.) Ah, I didn't realise that. Removed most, if not all of them. > I think we should probably wait for the Gash and Gash Core Utils > releases so we can refer to them directly. How does that sound to you, > Timothy? Incoroprated Gash 0.2.0! Greetings, janneke --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com