Re: [PATCH] gnu: commencement: Add support for a native GNU/Hurd system.

[Ludovic Courtès]

Hi!

Manolis Ragkousis <address@hidden> skribis:

> From 151868431cf3faafbf388dd2815745b3760ac12f Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis <address@hidden>
> Date: Fri, 24 Jun 2016 16:10:15 +0300
> Subject: [PATCH] gnu: commencement: Add support for a native GNU/Hurd system.
>
> * gnu/packages/commencement.scm (kernel-headers-boot0,
>   ld-wrapper-boot0, bison-boot0, flex-boot0, gnumach-headers-boot0,
>   mig-boot0, hurd-headers-boot0, hurd-minimal-boot0,
>   hurd-kernel-headers-boot0): New variables.
>   (bison-boot1): Remove.
>   (%boot1-inputs): Add ld-wrapper-boot0.
>   (glibc-final-with-bootstrap-bash)[arguments]: Allow libpthread
>   to find libihash.
>   [propagated-inputs]: Use kernel-headers-boot0.
>   [inputs]: Add "mig".
>   (glibc-final)[arguments]: Use kernel-headers-boot0.
>   (static-bash-for-glibc, bash-final)[native-inputs]: Use bison-boot0.

OK for ‘core-updates-next’.

Please also run something like this on GNU/Linux:

  ./pre-inst-env guix build -e '(@@ (gnu packages commencement) glibc-final)'

to make sure nothing obvious broke (this runs in a couple of hours on my
laptop IIRC.)


[...]

> +(define* (kernel-headers-boot0 #:optional (system (%current-system)))
> +  (match system
> +    ("i586-gnu" (hurd-core-headers-boot0))
> +    (_ (linux-libre-headers-boot0))))

In an subsequent patch, it might make sense to define ‘kernel-headers’
as a macro like you did for glibc; WDYT?

> +                 ;; Tell 'libpthread' where to find 'libihash' on Hurd 
> systems.
> +                 ,@(if (string-match "i586-gnu" (%current-system))

[...]

> +        ;; A native MiG is needed to build Glibc on Hurd.
> +        ,@(if (string-match "i586-gnu" (%current-system))

In a subsequent patch, could you add:

  (define* (hurd? #:optional (system (%current-system)))
    (string=? "i585-gnu" (%current-system)))

and use it?

That will make it easier on the day where GNU/Hurd supports other
arches.

These conditionals aren’t great in terms of readability/maintainability.
We should start thinking of a better approach, a mechanism similar in
spirit to “sysdeps” in glibc, which would allow us to weave
platform-specific concerns without having to wire conditionals
everywhere.  I don’t have a clear plan in mind, but there’s definitely
something to do here!

Thanks!

Ludo’.