Ludovic Courtès writes:

> Sorry for the delay, but this is awesome work!  I’m impressed that you
> got it working in so little time.

Thank you!  The way Guix (and Nix) handles builds, using clean
environments, together with the gcc-cross-environment-variables patch
makes it a lot less error-prone.

The fact that almost every little change triggers a full world rebuild
makes creating a cross build on Guix quite annoying, though.  I wonder
if we would like to make this friendlier, even if only to bootstrap
cross builds.

Our old GUB cross build system has two features that vastly reduce the
number of toolchain/world rebuilds

   * every package (class Name) can possbly have a architecture-specific
     specialisation: class Name__<arch>, that the build system looks
     for and uses if present

   * there is a `-x,--no-dependencies' option that says: just rebuild
     this package, even if some of its dependencies are out of date

I can speficy e.g. a modified Gcc for mingw only (GUB uses Python, my
favourite before I changed to Guile) like so

    class Gcc (cross.AutoBuild):
        ...

    class Gcc_core (Gcc):
        ...build minimal c-only compiler to build a libc...

    class Gcc__mingw (Gcc):
         ...add a patch for the c++ compiler to build...

Then the native toolchain won't be rebuilt when experimenting with
mingw.  To avoid rebuilding the core gcc and the c library when
working to get the c++ compiler built, I can use --no-dependencies
until it works, then suffer a full rebuild only once at the end.

> I’m not offering a full review yet.  I think it’s an additional
> incentive to finally merge the remaining bits from wip-hurd.  ;-)

Ok, thanks! :-)

> My main concern is the complexity of the cross-base stuff.  Why is
> ‘cross-gcc-core’ needed, for instance?

It is needed to break a circular bootstrap dependency.  To build a new c
library, you need a cross compiler.  A full flegded gcc can only be
built when you have a c library: the circular dependency.  This simple,
minimal `core-gcc' can be built with only the headers of the new c
library; breaking the circle.

> It’s probably inevitable for the complexity to be proportional to the
> number of target libcs, but I think we should start thinking about how
> to master this complexity by factoring/abstracting things a bit.

Okay.  It's cross-base is getting better but I/we haven't really
addressed this.  So no need to review that bit.  Meanwhile I'm offering
a new set of patches leading up to a mingw guile.exe for others to look
at and will look at refactoring cross-base.  Note that hello.exe runs
in wine

   ./pre-inst-env guix build --target=i686-w64-mingw32 hello

but guile.exe still segfaults.

> A cosmetic comment: I’d put the MinGW packages in a separate module.

Ok.

> I think portability patches should be (1) submitted upstream ;-), and
> (2) applied unconditionally on all architectures (assuming they do not
> make any difference on the other architectures.)

Yes, I agree.

Greetings,
Jan

on master: