-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
gnome: look up vapigen using pkg-config #15484
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
base: master
Are you sure you want to change the base?
Conversation
vapigen has architecture-dependent search path. In a cross build, using the native one cannot work as it cannot locate the host libraries it is supposed to use. On most distributions, vapigen.pc names location of vapigen (often suffixed with an appropriate version). On Debian, vapigen.pc points at an architecture-specific wrapper that adapts the search path for the desired architecture. It is never wrong to consult vapigen.pc and it also helps users with multiple vala installations selecting the right one. Thus prefer locating vapigen via its pc file over searching $PATH while retaining the override mechanisms available. Link: https://bugs.debian.org/1061107 Link: https://salsa.debian.org/gnome-team/vala/-/merge_requests/3 Related: 62a5e3a ("env2mfile: Use a cross vapigen on Debian if available") Thanks: Simon McVittie Thanks: Eli Schwartz
|
/cc @eli-schwartz |
|
Not a maintainer, but LGTM |
Slightly curious how this would work by the way. You'd need an unversioned pkgconfig file at the beginning of PKG_CONFIG_PATH instead of an unversioned binary at the beginning of PATH, and I think both are probably just as annoying. |
One of the ways of managing custom environments is using dedicated pkgconf "personalities", so you'd supply a custom pkgconf to meson and that way query packages from a particular location. I am not using this approach myself, but my understanding is that sysroots tend to use this. |
A package (dependency) can contain a mixture of native and architecture-dependent tools. Whether it is native or not, is a property of the tool. In particular, gio-querymodules happens to be architecture-dependent and is thus dropped. Suggested-By: Simon McVittie <smcv@debian.org>
34ca759 to
cdd20f9
Compare
vapigen has architecture-dependent search path. In a cross build, using the native one cannot work as it cannot locate the host libraries it is supposed to use. On most distributions, vapigen.pc names location of vapigen (often suffixed with an appropriate version). On Debian, vapigen.pc points at an architecture-specific wrapper that adapts the search path for the desired architecture. It is never wrong to consult vapigen.pc and it also helps users with multiple vala installations selecting the right one. Thus prefer locating vapigen via its pc file over searching $PATH while retaining the override mechanisms available.
Link: https://bugs.debian.org/1061107
Link: https://salsa.debian.org/gnome-team/vala/-/merge_requests/3
Related: 62a5e3a ("env2mfile: Use a cross vapigen on Debian if available")
Thanks: Simon McVittie
Thanks: Eli Schwartz