Hi, Ludovic Courtès <l...@gnu.org> 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. -- Ricardo
