[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap
From: |
Jan Nieuwenhuizen |
Subject: |
[bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap |
Date: |
Mon, 16 Dec 2019 20:28:02 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
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 <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, (continued)
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Jan Nieuwenhuizen, 2019/12/01
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Jan Nieuwenhuizen, 2019/12/06
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Ludovic Courtès, 2019/12/07
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Jan Nieuwenhuizen, 2019/12/11
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Ludovic Courtès, 2019/12/15
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Timothy Sample, 2019/12/15
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Brett Gilio, 2019/12/15
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Jan Nieuwenhuizen, 2019/12/16
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap,
Jan Nieuwenhuizen <=
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Jan Nieuwenhuizen, 2019/12/18
- [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap, Ludovic Courtès, 2019/12/19