guix-patches
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]