From: Jan Nieuwenhuizen <janneke@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Timothy Sample <samplet@ngyro.com>, 38390@debbugs.gnu.org
Subject: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap
Date: Mon, 16 Dec 2019 20:28:02 +0100 [thread overview]
Message-ID: <878sncm5od.fsf@gnu.org> (raw)
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")
Ludovic Courtès writes:
Hi!
>> I have just hard-reset wip-bootstrap for the next iteration!
>
> Yay!
and I did it again.
> Awesome.
>
> BTW, I’d 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)
>
> ‘caddr’, loooove it! ;-)
>
> It seems to me that mescc.scm in 0.21 only use the two-argument ‘map’,
> 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’.
> :-)
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 ‘mes’ 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 =' | wc -l
> 177
> $ guix graph -e '(@@ (gnu packages commencement) coreutils-final)' | grep 'label =' | wc -l
> 76
>
> Clearly we’re adding way more nodes than we mean to.
>
> For example, you can remove the call to ‘package-with-bootstrap-guile’
> for ‘bash-mesboot’ (down to 153 nodes) and the one for
> ‘gcc-core-mesboot1’ (down to 121) and the one for ‘binutils-mesboot’
> (down to 87), and I think at this point we’re 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 ‘bootstrap-origin’ for origins without
> a snippet and without patches (it’s 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
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
next prev parent reply other threads:[~2019-12-16 19:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 16:38 [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Jan Nieuwenhuizen
2019-12-01 14:01 ` Ludovic Courtès
2019-12-01 16:25 ` Timothy Sample
2019-12-01 16:55 ` Jan Nieuwenhuizen
2019-12-01 17:14 ` Ludovic Courtès
2019-12-01 17:21 ` Jan Nieuwenhuizen
2019-12-06 6:53 ` Jan Nieuwenhuizen
2019-12-07 22:31 ` Ludovic Courtès
2019-12-11 18:25 ` Jan Nieuwenhuizen
2019-12-15 21:33 ` Ludovic Courtès
2019-12-15 22:39 ` Timothy Sample
2019-12-15 22:45 ` Brett Gilio
2019-12-16 6:34 ` Jan Nieuwenhuizen
2019-12-16 19:28 ` Jan Nieuwenhuizen [this message]
2019-12-18 22:55 ` Jan Nieuwenhuizen
2019-12-19 11:08 ` Ludovic Courtès
2020-02-03 17:37 ` [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Timothy Sample
2020-02-05 8:58 ` Ludovic Courtès
2020-02-05 14:32 ` Timothy Sample
2020-02-05 21:33 ` Ludovic Courtès
2020-02-06 22:58 ` Jan Nieuwenhuizen
2020-02-07 11:00 ` Ludovic Courtès
2020-02-08 17:33 ` Timothy Sample
2020-02-08 22:32 ` Jan Nieuwenhuizen
2020-02-10 2:23 ` Timothy Sample
2020-02-11 13:56 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sncm5od.fsf@gnu.org \
--to=janneke@gnu.org \
--cc=38390@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=samplet@ngyro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).