unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
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

  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).