Orians, Jeremiah (DTMB) writes:
Ricardo, we love you dearly but please for the love of all that
is holy;
Get back to that vacation! *cracks whip* Burnout is a real thing
and believe me when I say bootstrapping is a marathon
In spite of making noise, burn out is such a terrible killer of
ambi
> 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.
Especially since those are the varieties that no one wants to be responsible
for maintaining.
> Right. We would need to cut out Guile on t
Hi,
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
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 G
Hello!
Jan Nieuwenhuizen skribis:
> Ludovic Courtès writes:
>
I think that's the main difficulty. I think we'd rather not have
separate bootstrap paths for Intel GNU/Linux on one hand, and everything
else on the other hand.
>>>
>>> Well, due to the design of mescc-tools; the boot
Orians, Jeremiah (DTMB) writes:
>> Gash seems to be a low-hanging fruit and a relatively easy thing,
>> because it's architecture-independent. How
>> far is it from being able to run typical 'configure' scripts?
> Well we would have to replace the parser at a bare minimum
Yes, the parser is bein
Ludovic Courtès writes:
>>> I think that's the main difficulty. I think we'd rather not have
>>> separate bootstrap paths for Intel GNU/Linux on one hand, and everything
>>> else on the other hand.
>>
>> Well, due to the design of mescc-tools; the bootstrap paths only have to be
>> divergent up
> Sounds nice. I wonder if Jan was referring to something else then?
Probably alternate operating systems like Hurd is my guess but I'm probably
wrong.
> There’s still the question of GNU/Hurd, though, which requires a vastly
> different libc.
Fortunately Janneke has done a good job making that
Hello OriansJ,
"Orians, Jeremiah (DTMB)" skribis:
>> I think that's the main difficulty. I think we'd rather not have
>> separate bootstrap paths for Intel GNU/Linux on one hand, and everything
>> else on the other hand.
>
> Well, due to the design of mescc-tools; the bootstrap paths only have
> I think that's the main difficulty. I think we'd rather not have
> separate bootstrap paths for Intel GNU/Linux on one hand, and everything
> else on the other hand.
Well, due to the design of mescc-tools; the bootstrap paths only have to be
divergent up to the M1-macro level.
After that, we c
Hello Jan!
Jan Nieuwenhuizen skribis:
> With Mes 0.16 released I felt that after two years of straight hacking
> I was pretty much done. Hmm...
>
> On the wip-bootstrap branch we have these packages
>
> binutils-2.20.1, gcc-2.95.3, and glibc-2.2.5
>
> built without using any of these 3 main
Hi!
With Mes 0.16 released I felt that after two years of straight hacking
I was pretty much done. Hmm...
On the wip-bootstrap branch we have these packages
binutils-2.20.1, gcc-2.95.3, and glibc-2.2.5
built without using any of these 3 main tools from the bootstrap
binaries.
Using these
12 matches
Mail list logo
