gtk3: support cross-compilation #148618
gtk3: support cross-compilation #148618
Conversation
Mindavi
added
the
6.topic: cross-compilation
|
gobject-introspection seems to be causing the most troubles cross compiling anything gtk related. Dropping that from every rev dep does not seem to be a viable solution to me. Shall we fix that first instead, even at the cost of bringing in qemu-user. My attempt here: NickCao@976dddb |
|
The upstream pr has been lying around for two months without any progress, maybe |
|
I'm in favor of making gobject-introspection work. I'm not in favor of emulation. If you want to emulate you can already use qemu-user to emulate a different target. That works already if you like to go that route. I'm also not a big fan of disabling introspection everywhere, but I don't really know where to start on dissecting gobject-introspection to make this work properly. Disabling introspection is a way to get further without blocking everything on gobject-introspection, so that's what I'm doing. Of course, some projects have a hard dependency on gobject-introspection, so there will be a point where it's inevitable to get that working. I'm mainly trying to get as far as possible while avoiding the biggest / hardest blockers, since to me it makes more sense for me to push forward than to block for months on one thing. I like to tackle the small issues more than to tackle the large issues. We could take that patch downstream, but we do need someone taking responsibility of maintenance, even if it's 'not that big'. I may look into it one day, but I'm not (yet) up for the challenge of getting that to work. Note that just having that patch does not make it magically work, it also needs work in nixpkgs to work properly, have correct setup hooks where needed etc. However, I'm open for a discussion. It's probably best to have that at 88222. |
Mindavi
force-pushed
the
gtk3/cross-compile
branch
from
77d9d4b
to
fa73f17
Compare
Mindavi
force-pushed
the
gtk3/cross-compile
branch
from
fa73f17
to
31d2611
Compare
Mindavi
force-pushed
the
gtk3/cross-compile
branch
from
31d2611
to
45734b0
Compare
|
So, I heard about this literally minutes after finishing #166219, which does the same thing. I only looked over this PR briefly, but it looks a lot cleaner than mine. I'm tired, I'll look more closely in the morning. Maintainers, please merge this |
This PR is way cleaner than what I wrote; it was clearly written by somebody who understands the gtk build process better than I do. Please merge this, or at least mark it not-a-draft, so I can close #166219. If there is still resistance to merging this, please consider merging the parts that aren't problematic (i.e. everything except introspection-disablement) plus a comment explaining that this is only partial support and perhaps a link to this discussion. It would have saved me a lot of wasted effort struggling with that (*^@!&^!$^ |
Is there anything (other than perhaps UI development tools) that absolutely requires the introspection data and won't work at all without it? My understanding was that pretty much everything will run without the introspection data, but will simply not allow introspection if the introspection data is missing. #166199 will make sure the introspection libraries (but not the generated data) are available, so builds shouldn't fail due to gobject-introspection being missing. |
|
The introspection data are required for bindings such as pygobject, gjs (at runtime) or gtk-rs (build time). In fact this is the main reason gobject-introspection was created. |
Ah, okay, I see.
Do you have a link for this? Mainly wondering: did somebody actually submit code to fix this to upstream and they're just sitting on it? In that case, isn't that sort of one of the major use cases that If the "upstream pr" is just a bug report and there's no implementation on the horizon, I could probably implement the "use qemu to generate the introspection data" approach. I got pretty good at doing qemu-in-nixexprs here and you can do some pretty slick stuff like 9pfs-mounting the host The main thing I'd need is a reliable way of automatically calculating a qemu-compatible kernel derivation from a |
|
The downstream work is in #88222, upstream in https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/224. The main obstacle is that everyone upstream is spread far too thin and there are often more pressing tasks than cross-compilation work. |
Mindavi
force-pushed
the
gtk3/cross-compile
branch
from
45734b0
to
441399c
Compare
Mindavi
force-pushed
the
gtk3/cross-compile
branch
from
441399c
to
1330c9e
Compare
|
Rebased on staging, gonna try and cross-compile gtk3. Mostly expecting that to work. If all goes well, I'd like to merge this. Any last objections here? Edit: failed to build because the patch doesn't apply anymore, will have to look into that. Edit 2: caused by this patch to gtk3: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4379, hopefully that means we can drop the whole patch here. I dropped all the ugly patches and applied a small patch to test cross-compilation of libhandy (which depends on gtk3): diff --git a/pkgs/development/libraries/libhandy/default.nix b/pkgs/development/libraries/libhandy/default.nix
index 38e540efd4e..e9367f30af3 100644
--- a/pkgs/development/libraries/libhandy/default.nix
+++ b/pkgs/development/libraries/libhandy/default.nix
@@ -31,6 +31,7 @@ stdenv.mkDerivation rec {
outputs = [
"out"
"dev"
+ ] ++ lib.optionals (stdenv.buildPlatform == stdenv.hostPlatform) [
"devdoc"
] ++ lib.optionals enableGlade [
"glade"
@@ -69,8 +70,9 @@ stdenv.mkDerivation rec {
];
mesonFlags = [
- "-Dgtk_doc=true"
+ "-Dgtk_doc=${lib.boolToString (stdenv.buildPlatform == stdenv.hostPlatform)}"
"-Dglade_catalog=${if enableGlade then "enabled" else "disabled"}"
+ "-Dintrospection=${if (stdenv.buildPlatform == stdenv.hostPlatform) then "enabled" else "disabled"}"
];
# Uses define_variable in pkg-config, but we still need it to use the glade outputWhich builds fine. I think this is a good start for better gtk3 cross support. We may have to do something about that post-install script that's now not executed anymore though. |
ofborg
bot
added
10.rebuild-darwin: 501-1000
and removed
10.rebuild-darwin: 1001-2500
labels
Mindavi
force-pushed
the
gtk3/cross-compile
branch
2 times, most recently
from
0e9e8a2
to
843181a
Compare
Mindavi
force-pushed
the
gtk3/cross-compile
branch
from
843181a
to
d97e95e
Compare
|
Cleaned this up a lot, hopefully this is actually enough to get it to run properly too. |
|
Everything builds now except gtk3 itself |
|
Still builds fine for me. |
ghost
mentioned this pull request
(Resolved)@piegamesde, @Mindavi didn't you have trouble cross-compiling `harfbuzz` without disabling the docs (i.e. https://github.com//pull/170826)?Also: Excellent, my dream of using my huge powerpc64le machine to do mass-rebuilds of my slow fanless laptop draws nearer... I really hope this PR gets merged. |
|
Maybe you are building for a different target platform? I've only tested |
This comment was marked as resolved.
This comment was marked as resolved.
|
@ofborg build pkgsCross.aarch64-multiplatform.gtk3 |
|
Something unrelated to this PR went wrong deep within (Resolved)I've closed #170826, I guess it is unnecessary. There must be a commit somewhere in |
|
Maybe this is due to a change introduced to If that is the case, I suggest merging as is and then do fixup PRs. |
|
Let's do that, may also be a flaky test, will be unrelated regardless. |
Motivation for this change
There are some hacks in here which are not very clean / nice.
In general, this does work fine though.
Installing gtk-query-immodules-3.0 is the worst part of this,
I wish we could avoid that or do something that doesn't make this part of the default closure.
Some tips and tricks would be welcome to make this nicer.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)