GNU bug report logs - #50201
[PATCH core-updates-frozen 0/52] Support cross-compilation in glib-or-gtk-build-system and fix cross-compilation errors

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 50201 <at> debbugs.gnu.org
Subject: [bug#50201] [PATCH core-updates-frozen 0/52] Support cross-compilation in glib-or-gtk-build-system and fix cross-compilation errors
Date: Mon, 30 Aug 2021 14:16:34 +0200

[Message part 1 (text/plain, inline)]

Mathieu Othacehe schreef op za 28-08-2021 om 15:33 [+0200]:
> Hello Maxime,
> 
> > It should not cause any rebuilds.  You can test with
> > ./pre-inst-env guix build gtk+ --target=aarch64-linux-gnu.
> > There is still some work to be done though:
> 
> Thanks for this series, that a great step forward. I will have a closer
> look later, but as a general remark, should we really target the 
> core-updates-frozen branch? 
>
> Maybe it would make more sense to target the core-updates branch as
> there's still some work required to get gtk+ to cross-build.

Going by the patch series title: ‘Support cross-compilation in
glib-or-gtk-build-system’, I don't see why this would have to go in
core-updates instead of core-updates-frozen, because:

  (1) no rebuilds, unless I missed something (*)
  (2) due to (1), it doesn't introduce bugs
  (3) after this patch series, glib-or-gtk-build-system _does_ support
      support cross-compilation

(*) In one patch, I unconditionally added a glib:bin input.  IIRC, it failed
    to build natively previously, but I'd better check again ..

For example, cairo, which uses glib-or-gtk-build-system, now cross-compiles
for aarch64-linux-gnu.  True, ideally gtk+ would cross-compile as well,
but cairo being cross-compilable is already useful (e.g., it's a
dependency of harfbuzz which is a dependency of qtbase which is a dependency
of graphical Qt software.) (**)

(**) qtbase (indirectly) depends on perl-file-mimeinfo and 'perl-build-system'
doesn't support cross-compilation, so this argument is probably not really
convincing ...  Maybe texlive-bin would be a
better example?(***)
(***) The dependency libungif fails to cross-compile/

Also, hacking on master (or core-updates-frozen) is simpler on than on core-updates,
due to more substitutes, and it is more appealing to me because the cross-compilation
support would be available earlier to most people than if it the patches were based
on core-updates.

As a general principle, I prefer basing patches on 'master'.  That wasn't possible
here due to the use of G-exps in glib-or-gtk-build-system, so I based the patches
on 'core-updates-frozen' instead.  That goes a bit against
(guix)Submitting Patches though, so I would understand if the patches will have to
be rebased on core-updates:

  When we decide to start building the ‘staging’ or ‘core-updates’
  branches, they will be forked and renamed with the suffix
  ‘-frozen’, at which time only bug fixes may be pushed to the frozen
  branches.

unless ‘let glib-or-gtk-build-system support cross-compilation’ counts as a bug fix.
To me, this is not all that different from other cross-compilation fixes like
"CC=gcc" --> (string-append "CC=" (cc-for-target)) or moving inputs between
'native-inputs' and 'inputs', but YMMV.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.