Skip to content
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

Allow overriding g-ir-scanner and g-ir-compiler binaries. #7072

Merged
merged 1 commit into from
May 7, 2020

Conversation

jameshilliard
Copy link
Contributor

This is useful when one needs to force meson to use wrappers for cross compilation.

@jpakkane
Copy link
Member

jpakkane commented May 3, 2020

Who knows the most about this? @xclaesse?

@xclaesse
Copy link
Member

xclaesse commented May 5, 2020

Hmm, there are 4 places that tool can come from:

  • Overridden by gobject-introspection as subproject
  • Path set by user in cross/native file
  • Path set in pkgconfig file
  • In system $PATH

However, since a pkgconfig file is required and always contains a path to those tools, I'm not sure to understand use cases for having it in cross/native file and lookup in system PATH. Why do you need a wrapper?

@jameshilliard
Copy link
Contributor Author

jameshilliard commented May 5, 2020

Path set by user in cross/native file

So essentially that is what this makes possible for those particular binaries, otherwise the ones found by pkgconfig are used unconditionally.

a pkgconfig file is required and always contains a path to those tools

Is this actually a requirement of gobject-introspection or is it a meson requirement?

So essentially the pkgconfig file in the build(host in buildroot terms) system pkgconfig lib path used for native: true dependencies meson finds by default only contains valid binaries for generating artifacts that would run on the build(host in buildroot terms) system, while the valid wrapper variants for the host(target in buildroot terms) are in the host pkgconfig lib path, the one used for native: false dependencies.

Why do you need a wrapper?

You need a qemu wrapper to cross compile with these tools.

mesonbuild/modules/gnome.py Outdated Show resolved Hide resolved
mesonbuild/modules/gnome.py Outdated Show resolved Hide resolved
This is useful when one needs to force meson to use wrappers for cross
compilation.

Signed-off-by: James Hilliard <[email protected]>
@xclaesse
Copy link
Member

xclaesse commented May 7, 2020

OK, fine with me.

@xclaesse xclaesse merged commit 1e073c4 into mesonbuild:master May 7, 2020
@jameshilliard jameshilliard deleted the gir branch May 7, 2020 14:21
Ericson2314 added a commit to Ericson2314/meson that referenced this pull request May 16, 2020
gobject-introspection is infamous for being difficult to get working
with cross compilation. But the situation has improved recently with
https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/64,
thanks to @kanavin from the Yocto project. The upshot is now only
*some*, not all, of the executables need to be run on the host platform
with the exe wrapper.

On the meson side, there have been two attempts to fix things for cross:

- https://github.com/mesonbuild/meson/pull/2965from @kanavin and the
Yocto projejct, which because it predates
mesonbuild#4010 had to be somewhat hacky

- mesonbuild#7072 recently merged which
allows specifying some binaries with a cross file.

But, I think we can make a more seamless user interface that won't
require extra config, like for native builds. gobject-introspection
provides the binaries in its pkg-config file, and Meson now cleanly
supports separate `native: true` and `native: false` pkg-config paths
and lookup.

We should just need to add separate `native: true` and `native: false`
deps, and I have done that, but I am not sure exactly which should be
used when. I am coming at this as a distro maintainer not even
particularly involved with gnome things and so I'll need some advice on
what to do next.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants