[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bootstrap integration strategies
From: |
Jan Nieuwenhuizen |
Subject: |
Re: bootstrap integration strategies |
Date: |
Fri, 13 Jul 2018 16:19:39 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Ludovic Courtès writes:
>> So what I was saying is probably: we have x86 NOW, can we use it and do
>> we want that somehow? OR do we plan some of the work above, and go that
>> route?
>
> I think we should try and use what we have now in ‘wip-bootstrap’, and
> keeps things unchanged for ARM and GNU/Hurd. Ricardo?
Yes, let's also ask Ricardo.
>> Yes, performance is really the thing here. Currently, mes is about 30x
>> slower than Guile. It will definately not work if mes has to interpret
>> all of gnu/packages/*.scm, it may work if we can do something smart.
>
> No no, in my view we’d use Mes simply as the guile-for-build in the
> early derivations (the interpreter that runs the build phases from (guix
> build build-system)).
OK...
> It’s a job where we don’t need much performance, but we need the POSIX
> layer—‘system*’, (ice-9 ftw), and so on.
Mes has system*, no ice-9 ftw yet, not sure about the so on; adding
things like these should be fun though.
> My hesitation comes from the fact that this will increase maintenance
> cost on the Guix side. At the same time, this is clearly the direction
> we want to take, and I such I think we have to get our act together and
> go forth.
Agreed. That's important to keep an eye on. A requirement for a
bootstrap process is also its transparency.
> What’s the exact status of ‘wip-bootstrap’ on non Intel arches? Is it
> still like ‘master’? If it is, that’s fine.
> Does it use the Mes/MesCC/tcc path for i686 only, or is it i686 +
> x86_64? (I would expect the latter.)
I haven't started integrating the bootprocess at all, not even for
i686/x86_64; there's only an alternative path to build gcc-4.7.4 atm.
That i686x86 gcc can be built on i686 and x86_64:
./pre-inst-env guix build gcc-mesboot
it's advisable to set
(define %fake-bootstrap? #t) ; cheat using Guile instead of Mes for
speed-up?
in gnu/packages/mes.scm at first; set it to #f later and let it run
overnight :-)
> If there are no regressions, I’d be willing to simply merge it in
> core-updates. I’d like some of us to take another look at it—Ricardo,
> Mark, and anyone with an interest in this. And then I guess we could
> go.
>
> How does that sound?
That's really great...but we need integration work into the x86
bootstrap first too. Do you/Ricardo want to help with that too?
> Thank you for your patience!
Thanks for your help and support!
janneke.
--
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
- bootstrap integration strategies, Jan Nieuwenhuizen, 2018/07/09
- Re: bootstrap integration strategies, Orians, Jeremiah (DTMB), 2018/07/12
- Re: bootstrap integration strategies, Ludovic Courtès, 2018/07/12
- RE: bootstrap integration strategies, Orians, Jeremiah (DTMB), 2018/07/12
- Re: bootstrap integration strategies, Jan Nieuwenhuizen, 2018/07/12
- Re: bootstrap integration strategies, Jan Nieuwenhuizen, 2018/07/12
- Re: bootstrap integration strategies, Ludovic Courtès, 2018/07/13
- Re: bootstrap integration strategies,
Jan Nieuwenhuizen <=
- Re: bootstrap integration strategies, Ricardo Wurmus, 2018/07/13
- RE: bootstrap integration strategies, Orians, Jeremiah (DTMB), 2018/07/16
- Re: bootstrap integration strategies, Brett Gilio, 2018/07/16
Re: bootstrap integration strategies, Jan Nieuwenhuizen, 2018/07/12