[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bootstrap integration strategies

From: Ricardo Wurmus
Subject: Re: bootstrap integration strategies
Date: Fri, 13 Jul 2018 20:23:32 +0200
User-agent: mu4e 1.0; emacs 26.1


Ludovic Courtès <address@hidden> 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?

I agree.  We need to make sure, though, that the Guix build
infrastructure doesn’t add more complicated packages to the environment
that are not needed.

>>>>> there's also another option you didn't mention: ditching the 2.0
>>>>> bootstrap Guile in favor of Mes.  That can be done in several steps:
>>>>>  1. Replace the guile-2.0.*.xz binary tarballs with Mes, and add a step
>>>>>      that builds Guile 2.x using our big bootstrap GCC binary.
>>>> Slow but possible
>> 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)).
> It’s a job where we don’t need much performance, but we need the POSIX
> layer—‘system*’, (ice-9 ftw), and so on.

Right.  We would need to cut out Guile on the build side.

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

I would love to take a closer look again before merging it.
Unfortunately, these days I’m a bit short on time as I’m on “vacation”
with other plans imposed on my schedule.


reply via email to

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