| Message ID | ae9b811656ee605563cceaf617d079fff0433542.camel@telenet.be |
|---|---|
| Headers | show |
| Series | Support cross-compilation in glib-or-gtk-build-system and fix cross-compilation errors | expand |
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. Mathieu
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.
Maxime Devos schreef op wo 25-08-2021 om 19:55 [+0200]: > Hi guix, > > This patch series does two things: > > * let 'glib-or-gtk-build-system' support cross-compilation > > * fix many (but not all) cross-compilation errors that prevent > "guix build gtk+ --target=aarch64-linux-gnu" from succeeding. > > It should not cause any rebuilds. You can test with > ./pre-inst-env guix build gtk+ --target=aarch64-linux-gnu. Be aware that I don't have an aarch64-linux-gnu machine to test this on. Some binaries of some packages I've run through qemu-aarch64 and I've run "guix gc --references [...]" on a few store items to check if it looks reaonable, but that's it. Greetings, Maxime.
Hello Maxime, > 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 .. I made this suggestion mostly because there are quite a few "TODO(core-updates)" that could be spared by basing this series on core-updates directly. > 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. Yeah this series is near the limit between a bug fix and a feature addition. Anyway, let's go for the core-updates-frozen branch if there are no other objections. Thanks, Mathieu
Hi guix, This patch series does two things: * let 'glib-or-gtk-build-system' support cross-compilation * fix many (but not all) cross-compilation errors that prevent "guix build gtk+ --target=aarch64-linux-gnu" from succeeding. 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: cannot build derivation `[...]-cups-filters-1.28.9.drv': 1 dependencies couldn't be built [...] `[...]-cups-2.3.3op2.drv': 1 dependencies couldn't be built [...] `[...]-samba-4.13.10.drv': 6 dependencies couldn't be built [...] `[...]-libsoup-2.72.0.drv': 4 dependencies couldn't be built [...] `[...]-rest-0.8.1.drv': 1 dependencies couldn't be built Greetings, Maxime