-
-
Notifications
You must be signed in to change notification settings - Fork 13.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: gobject-introspection: Support cross #88222
Conversation
e635ef9
to
7d6ea7d
Compare
Where do docs fit into this #87904? |
@jtojnar Those look perfectly compatible for me :), We could build them with the python stuff or the C stuff. If you merge your PR I'll be happy to rebase mine on top. |
Do all dependents of gobject-introspection need exe_wrapper? When cross compiling nixos, I ended up having to disable gobject-introspection, vala, and gtk-docs. It ends up working pretty well, since you're already building everything from scratch, and I've never encountered a point where I need any of the 3 (matthewbauer@f33e8c3). Annoyingly there are a few things that you have to patch to disable introspection correctly. |
The exe wrapper is sadly mandatory for anything generating typelibs (compiled gir files), but anything purely consuming them at runtime doesn't need the exe wrapper: it just links I would like to split up the package (different wrappers around specific outputs from the two underlying builds) to reflect this. |
Well I would be kind of surprised if you needed the emulator at runtime - it would be the cross compiled architecture :) Meson could just provide exe_wrapper everywhere for consistency. qemu-user at least has few dependencies. |
nixStoreDir = config.nix.storeDir or builtins.storeDir; | ||
inherit (darwin) cctools; | ||
}; | ||
|
||
gobject-introspection-py-tools = gobject-introspection-full-classic.override { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the when to use what? It's not clear from the commit message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I think I'll need to make a wrapper package so this isn't actually used directly. But the idea is (whether directly or via some wrapper) than the py tools are need when generating new gir files and type libs when building some C library, and aren't needed by the programs in python etc that just consume typelibs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think we should make that distinction if it’s not made by gobject introspection. IIUC things that consume gir also produce gir without much distinction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine, but we will need the wrapper anyways to combine the build platform py tools with host platform everything else.
7d6ea7d
to
9ffa327
Compare
This is from the Yocto Project, and contains maintainence to the original work + newer cross features. (There separate brances for each to distinguish.)
9ffa327
to
278bf51
Compare
Let's assume that NIX_PATH is already setup correctly (the channel nixos-19.09 might not exist anyway). Note: The cross-compilation of the full image currently depends on [0]. [0]: NixOS/nixpkgs#88222
I'm happy to say https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/227 was finally merged 11 months later. Hopefully https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/224, which thus became much smaller and simpler, has a chance of being merged now. Then we can finish this off. |
See also discussion about this in the WIP PR from @Ericson2314: - NixOS#88222 Related issue: - NixOS#72868
See also discussion about this in the WIP PR from @Ericson2314: - #88222 Related issue: - #72868
See also discussion about this in the WIP PR from @Ericson2314: - NixOS#88222 Related issue: - NixOS#72868
What's the status on this? One of the patches was merged a few months ago. |
rebased in https://github.com/Artturin/nixpkgs/tree/gobject-introspectcross during build it fails with
need this for tests https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/224 |
@Artturin @SuperSandro2000 the remaining is https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/224 is small enough that we could try to just do it downstream, and then use that to try to get the maintainer's attention. I am pulled in many directions right now and don' feel I have the time/energy to push this, but if someone else wants to give it a shot I would be very happy to mentor them. (This also can help me be less of a chokepoint with this sort of upstream-adventure-for-better-bootstrapping stuff in general.) |
I marked this as stale due to inactivity. → More info |
Do we actually need the patch at all? Could we just build everything both times and throw away what we don't need? That would be a bit wasteful for processing power but maintaining the patch is also much work in the long run. |
Motivation for this change
The idea is to build the python tools separate from the C bits, and the python tools are run natively (including C extension module, in particular), but the C bits are either the installed library, or tools that must be run with an emulator (during cross compilation) and in both cases are non-native.
I need to still need to wrap the two together for downstream consumption, and I am also debating exactly how I'd like to do that.
CC @jtojnar @samueldr
Upstream issue: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/337
Upstream PR: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/224
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)