PKG_CONFIG_SYSROOT_DIR expansion API inconsistencies #69
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
pkg-config(1) states PKG_CONFIG_SYSROOT_DIR "Modify -I and -L to use the directories located in target sysroot.". Pkgconf injects PKG_CONFIG_SYSROOT_DIR in ${prefix} instead. This makes various outputs inconsistent between both utilities.
Tested pkg-config-0.28 against pkgconf-84050f8fd.
https://gist.github.com/nipo/8e549d11f593acb50f92 is a test case which outputs:
.pc file:
prefix=/usr
datarootdir=${prefix}/share
libdir=${prefix}/lib
otherlibdir=/non/prefix/lib
Version: 0.1
Name: Test package
Description: Lol
Cflags: -DTEST
Libs: -L${libdir} -L${otherlibdir} -ltest -ltest-1
PKG_CONFIG_LIBDIR=/tmp/test-31000
PKG_CONFIG_SYSROOT_DIR=/lol
Results differ for --variable=libdir:
pkgconf test --variable=libdir
/lol/usr/lib
pkg-config test --variable=libdir
/usr/lib
Result OK for --variable=otherlibdir:
/non/prefix/lib
Results differ for --libs:
pkgconf test --libs
-L/lol/usr/lib -L/non/prefix/lib -ltest -ltest-1
pkg-config test --libs
-L/lol/non/prefix/lib -ltest -ltest-1
With
12ff14f856, we now handle sysroot_dir differently.However, our current behaviour is to overload paths from variables with PKG_CONFIG_SYSROOT_DIR when set, as before. The reason why is because many modules do this:
And then in their build configuration files, they do this:
It is our goal that the sysrooted headers are used instead of the system ones in these cases. I would like to stress that it is not a goal of pkgconf to provide 100% exactly the same behaviour as pkg-config in all cases. If you have a specific use-case for the freedesktop behaviour, we could add a runtime option to force non-munged output with PKG_CONFIG_SYSROOT_DIR.
Thoughts?
I just added an explicit check for the variable output munging which ensures we do not inject the sysroot dir as a duplicate, this is the main 'pain point' I suspect between pkgconf and pkg-config in that area.
If this isn't what you need, let me know explicit issues you are having and your views for changing the current behaviour and we will consider them.
Use case with sdkdir is legitimate, but I've also seen packages do:
then in configure.ac
MODULE_DIR=$($PKG_CONFIG --variable plugindir foo)and use$(MODULE_DIR)for an install path.With
PKG_CONFIG_SYSROOT_DIR=/lol, pkg-config does not prepend /lol but pkgconf does. pkg-config behavior is preferred since wemake install DESTDIR=/lolafterwards, and want to avoid double prefix (this is the behavior I was bitten by).pkg-config's man (thus its API) explicitly tells it only modifies -I and -L, nothing else. Pkgconf tagline states "API-driven pkg-config replacement", which is, for this very point, not the case. That's what I expected from pkgconf when it was aliased as pkg-config on my system.
To me, we should not do any duck-typing on variable contents. It's not because it starts with a '/' that it is a path, it's not because it is a path that it should be prefixed with sysroot.
It's up to library .pc author to tell whether sysroot prefix is needed, and add ${pc_sysrootdir} if relevant. Automagic prefixing of -I and -L in pkg-config is a hack, for sure, but it's API.
Output munging from
3d98bd7seems broken to me, we cannot guarantee paths will never start with $pc_sysroot legitimally (in a way that path should really look like $pc_sysroot has been doubled).Again this was implemented in this way intentionally because everyone agreed that the pkg-config behaviour was broken. We can add an option to force the pkg-config behaviour. The default behaviour in regards to sysroot is not likely to change without a much stronger rationale than "pkg-config does it that way." We made pkgconf, because we felt that pkg-config had deficits in many areas.