Improve pkg-config file generation
kmilos opened this issue · comments
It would be good to improve the CMake generated .pc file for relocatability - namely, it should use ${prefix} etc. variables and relative paths whenever possible, but still support absolute paths when so required.
Same goes for OpenEXR btw...
While I support the suggestion of using ${prefix} etc., I don't know of a case, where relative paths are used. From the almost 1200 pkg-config files on my machine, only a handful uses relative paths and all of them look like the generation of the files was buggy and the paths were not properly expanded during file generation. Also the pkg-config documentation you linked doesn't mention relative paths. It speeks of installation paths, which IMO should always be absolute paths.
I don't know of a case, where relative paths are used.
With the known exception of NixOS (there might be others though), CMAKE_INSTALL_LIBDIR etc. seem to be always relative.
Using exclusively absolute paths in the pkg-config file prevents the package from being relocatable (see the --define-variable= example of the pkg-config man page).
From the almost 1200 pkg-config files on my machine, only a handful uses relative paths
From the more modest 249 on mine, only 23 use absolute paths.
With the known exception of NixOS (there might be others though),
CMAKE_INSTALL_LIBDIRetc. seem to be always relative.
Yes it's usually relative. There's CMAKE_INSTALL_FULL_LIBDIR from the GNUInstallDirs which are guaranteed to be absolute paths. But if you prepend the {exec_,}prefix to it, it will always be an absolute path.
Imath uses the *_FULL_*DIR variables and so is IMO not affected by the issue from the NixOS discussion you linked, but can indeed lead to issues when relocating. That's why I said, I like the ${prefix} notation.
From the more modest 249 on mine, only 23 use absolute paths.
Do you have an example?
The generation has been changed in 2496f3e
But this doesn't support relocation, and the previous didn't support absolute paths.
That's why I linked the issue above - to show a lot of consideration has gone into this to support both absolute paths and relocation, and libjxl and libtiff get it right so far.
Do you have an example?
Sure, the 23 using absolute paths on my system are:
freeglut.pc
Imath.pc
jasper.pc
lensfun.pc
libavif.pc
libdeflate.pc
libgit2.pc
libjpeg.pc
liblzma.pc
libqpdf.pc
libturbojpeg.pc
libuv-static.pc
libuv.pc
mozilla-nss.pc
nss.pc
OpenEXR.pc
poppler-cpp.pc
poppler-glib.pc
poppler.pc
portmidi.pc
pugixml.pc
SvtAv1Dec.pc
SvtAv1Enc.pc
The expected contents of libjxl.pc (for my system which is not using absolute paths like NixOS):
prefix=/ucrt64
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libjxl
Description: Loads and saves JPEG XL files
Version: 0.7.0
Requires.private: libhwy libbrotlicommon libbrotlienc libbrotlidec lcms2
Libs: -L${libdir} -ljxl
Libs.private: -lm
Cflags: -I${includedir}
Cflags.private: -DJXL_STATIC_DEFINE
(libdeflate already changed on master as I made a similar report, and I also requested at libavif and SVT-AV1...)
But the libjxl example you listed also uses absolute paths. prefix=/ucrt64 is an absolute path. In your opening thread, you're talking about the generated .pc files supporting absolute and relative paths. I'm still not convinced there are .pc files with relative paths in it. I've never seen a pkg-config file like
prefix=../..
I'm having files that have
prefix=${pcfiledir}/../..
which looks like a relative path, but is still an absolute path. If you call pkg-config --variable=prefix <pkg> on it, you get the absolute path of the .pc file location prepended to the /../.. suffix, in my case /usr/lib64/pkgconfig/../.. which is an absolute path. The ${pcfiledir} seems to be an pkg-config internal variable which expands to the absolute path of the .pc files location.
The generation of the files is a different matter, and I say it again, I support the idea of using ${prefix} notation to make the files relocatible and improve the logic to support both absolute and relative paths in the CMAKE_INSTALL_* variables.
Ok, if you want to be picky, relative to $prefix in terms of relocatability then. Of course $prefix has to be set to something initially, but then you have the pkg-config --define-variable=prefix=/foo mechanism (and configure --prefix=/foo, meson --prefix /foo, etc.) to relocate it (and the rest of the package artefacts together) wherever.
This doesn't work if $libdir and $includedir are absolute (excluding NixOS here).
Oh it's not about being picky. IMO it's more about people from different regions have a different interpretation of english, especially if it's not their native language and about trying to communicate as precise as possible in such circumstances.
And the 4th time, in the hope, you won't ignore it further:
The generation of the files is a different matter, and I say it again, I support the idea of using ${prefix} notation to make the files relocatible and improve the logic to support both absolute and relative paths in the
CMAKE_INSTALL_*variables.
I was just extremely confused, what you're talking about relative path's in .pc files.
No probs, glad we converged.
With the known exception of NixOS (there might be others though),
CMAKE_INSTALL_LIBDIRetc. seem to be always relative.
It purely depends on how you define -DCMAKE_INSTALL_LIBDIR at configure time. This is in contrast to e.g. Meson, where you can pass --prefix=/usr --libdir=/usr/lib and it will be consistently relativized for you. It's important for cases where these paths aren't necessarily a single constant location.
(But Meson doesn't have this problem anyway, because pkg-config file creation is a core feature of Meson and handles all the edge cases for you. It even supports prefix=${pcfiledir}/../../ without individual projects having to hardcode support for it -- all it took was a small patch to Meson itself, so that all projects benefited. It's a great shame that cmake doesn't care to provide support for pkg-config.)
It purely depends on how you define
-DCMAKE_INSTALL_LIBDIRat configure time.
That's the thing, why would one have to define both CMAKE_INSTALL_{LIBDIR,INCLUDEDIR}? Defining -DCMAKE_INSTALL_PREFIX should suffice, and CMake figures out CMAKE_INSTALL_{LIBDIR,INCLUDEDIR} correctly as relative to that in most cases. The problem then is that on some platforms, like nixOS, those are not relative to the prefix, but absolute, so this needs to be managed like in the examples above. I don't see a need to burden the users of Imath with further configuration options. Besides, the current Imath pkg-config template doesn't even use CMAKE_INSTALL_{LIBDIR,INCLUDEDIR} variables, but CMAKE_FULL_INSTALL_{LIBDIR,INCLUDEDIR}, so one has to provide an absolute path there (you can't define it as something like "\${exec_prefix}/lib" as it might be used elsewhere in CMake scripts), which doesn't solve the relocation issue...
But Meson doesn't have this problem anyway, because pkg-config file creation is a core feature
Not discussing pkg-config file creation by Meson here, but by CMake. I used Meson just as an example on how one can consume a relocatable pkg-config file properly generated by whatever build system.
Just getting to this now. Take a look at #291, I think that's what you're suggesting, but I don't use pkg-config much, so please confirm this works as you'd expect. If so, I'll submit the similar fix for openexr. Thanks.