Re: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

Re: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Ludovic Courtès]

Howdy!

guix-commits@gnu.org skribis:

> commit 26973d51c37e6921454a4500fb95bcda11ea4ec8
> Author: Efraim Flashner <efraim@flashner.co.il>
> AuthorDate: Fri Jan 31 16:28:23 2020 +0200
>
>     DRAFT gnu: bootstrap: Add support for the Hurd.

[...]

> @@ -378,18 +394,40 @@ or false to signal an error."
>                    (rename-file guile guile-real)
>                    (call-with-output-file guile
>                      (lambda (p)
> -                      (format p "\
> +                      (format p ,(if (equal? (or (%current-target-system)
> +                                                 (%current-system)) "i586-gnu") "\
> +#!~a
> +export GUILE_SYSTEM_PATH=~a/share/guile/2.2
> +export GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.2/ccache
> +exec -a \"~a0\" ~a \"~a@\"\n"
> +                                     "\
>  #!~a
>  export GUILE_SYSTEM_PATH=~a/share/guile/2.0
>  export GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.0/ccache
>  exec -a \"~a0\" ~a \"~a@\"\n"
> +
> +)
>                                bash out out dollar guile-real dollar)))
>                    (chmod guile   #o555)
>                    (chmod bin-dir #o555))))))

For the sake of reducing complexity and keeping supported systems as
close to one another as possible, would it be an option to keep using
2.0 for GNU/Hurd, like on the other systems?

That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
as a first step.  And yeah, it’d also entail another full rebuild, which
I’m sorry for, but I think this kind of simplification pays off quickly.

WDYT?

(I vaguely remember discussing it before but I forgot the outcome of the
discussion.  Apologies for that!)

Thanks,
Ludo’.

Re: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello Ludo' and All,

>>     DRAFT gnu: bootstrap: Add support for the Hurd.
>
> [...]
>
>> @@ -378,18 +394,40 @@ or false to signal an error."
>>                    (rename-file guile guile-real)
>>                    (call-with-output-file guile
>>                      (lambda (p)
>> -                      (format p "\
>> +                      (format p ,(if (equal? (or (%current-target-system)
>> +                                                 (%current-system)) "i586-gnu") "\
>> +#!~a
>> +export GUILE_SYSTEM_PATH=~a/share/guile/2.2
>> +export GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.2/ccache
>> +exec -a \"~a0\" ~a \"~a@\"\n"
>> +                                     "\
>>  #!~a
>>  export GUILE_SYSTEM_PATH=~a/share/guile/2.0
>>  export GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.0/ccache
>>  exec -a \"~a0\" ~a \"~a@\"\n"
>> +
>> +)
>>                                bash out out dollar guile-real dollar)))
>>                    (chmod guile   #o555)
>>                    (chmod bin-dir #o555))))))
>
> For the sake of reducing complexity and keeping supported systems as
> close to one another as possible, would it be an option to keep using
> 2.0 for GNU/Hurd, like on the other systems?

I'm pretty sure that will work; I have a patch set to do that somewhere.

> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
> as a first step.  And yeah, it’d also entail another full rebuild, which
> I’m sorry for, but I think this kind of simplification pays off quickly.
>
> WDYT?

Yes, let's do that.  I'll also want to look at using gcc-5, that may
solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
build gcc-7 by default as bootstrap binary, while using that may not
even work (and is certainly untested).

> (I vaguely remember discussing it before but I forgot the outcome of the
> discussion.  Apologies for that!)

Yes, we discussed it...my focus at the time however was rather that 2.0
might be necessary, but that moving to 2.2 might be preferred (for
Guix'y reasons or possibly Hurd'y reasons -- I forgot).

FWIW, yes the rebuilds are annoying but I find managing/juggling
different working setups especially cumbersome.  A rebuild takes about a
half a day round-trip time and during that I'm also doing development.
I want to test smaller changes but am also making changes that will
trigger another rebuild.  Also, I don't want to lose my last working
setup (VM+git).  For that I'm creating many branches, tagged with
numbers (wip-hurd0, wip-hurd-system3; etc), which "works" but...  Just
wondering how you all handle this kind of thing.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#40006: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

>> For the sake of reducing complexity and keeping supported systems as
>> close to one another as possible, would it be an option to keep using
>> 2.0 for GNU/Hurd, like on the other systems?
...
>> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
>> as a first step.  And yeah, it’d also entail another full rebuild, which
>> I’m sorry for, but I think this kind of simplification pays off quickly.
>>
>> WDYT?
>
> Yes, let's do that.  I'll also want to look at using gcc-5, that may
> solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
> build gcc-7 by default as bootstrap binary, while using that may not
> even work (and is certainly untested).

Yes; that worked and it simplifies things a lot.  So, wip-hurd is using
guile-2 and gcc-5 now.  Using gcc-5 allowed me to remove the puzzling
gcc-boot0 patch.

Just reset wip-hurd again; it was fully up to date with core-utils when
I started building the bootstrap-tarballs... Rebasing right now to
verify for a new round ;-)

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

>> For the sake of reducing complexity and keeping supported systems as
>> close to one another as possible, would it be an option to keep using
>> 2.0 for GNU/Hurd, like on the other systems?
...
>> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
>> as a first step.  And yeah, it’d also entail another full rebuild, which
>> I’m sorry for, but I think this kind of simplification pays off quickly.
>>
>> WDYT?
>
> Yes, let's do that.  I'll also want to look at using gcc-5, that may
> solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
> build gcc-7 by default as bootstrap binary, while using that may not
> even work (and is certainly untested).

Yes; that worked and it simplifies things a lot.  So, wip-hurd is using
guile-2 and gcc-5 now.  Using gcc-5 allowed me to remove the puzzling
gcc-boot0 patch.

Just reset wip-hurd again; it was fully up to date with core-utils when
I started building the bootstrap-tarballs... Rebasing right now to
verify for a new round ;-)

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> FWIW, yes the rebuilds are annoying but I find managing/juggling
> different working setups especially cumbersome.  A rebuild takes about a
> half a day round-trip time and during that I'm also doing development.
> I want to test smaller changes but am also making changes that will
> trigger another rebuild.  Also, I don't want to lose my last working
> setup (VM+git).  For that I'm creating many branches, tagged with
> numbers (wip-hurd0, wip-hurd-system3; etc), which "works" but...  Just
> wondering how you all handle this kind of thing.

I use git worktrees.

Now, I think the main limitation is mind availability.  For some reason,
earlier during Guix development, I’d manage to do core-updates testing
in parallel with unrelated things on master.  Nowadays, I find it harder
to be on more than one front at a time.  Maybe I just got older?  :-)

Perhaps one way to reduce the burden is to work on smaller, more focused
changes.  Perhaps “GNU/Hurd support” is too broad a topic for a branch
and you could instead target intermediate milestones?  At least that
would more often give a feeling of achievement, which I find important
to stay motivated.

My 2¢…
Ludo’.

bug#40006: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

On Sun, Mar 15, 2020 at 07:23:52PM +0100, Jan Nieuwenhuizen wrote:
> Jan Nieuwenhuizen writes:
> 
> >> For the sake of reducing complexity and keeping supported systems as
> >> close to one another as possible, would it be an option to keep using
> >> 2.0 for GNU/Hurd, like on the other systems?
> ...
> >> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
> >> as a first step.  And yeah, it’d also entail another full rebuild, which
> >> I’m sorry for, but I think this kind of simplification pays off quickly.
> >>
> >> WDYT?
> >
> > Yes, let's do that.  I'll also want to look at using gcc-5, that may
> > solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
> > build gcc-7 by default as bootstrap binary, while using that may not
> > even work (and is certainly untested).
> 
> Yes; that worked and it simplifies things a lot.  So, wip-hurd is using
> guile-2 and gcc-5 now.  Using gcc-5 allowed me to remove the puzzling
> gcc-boot0 patch.
> 
> Just reset wip-hurd again; it was fully up to date with core-utils when
> I started building the bootstrap-tarballs... Rebasing right now to
> verify for a new round ;-)

I haven't been looking at the wip-hurd branch that much, but I tested my
libstdc++-boot0 patch on aarch64 using gcc-7 with bootstrap binary gcc-5
and it failed to build. I didn't investigate.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]