On Friday 18 November 2011, Alan W. Irwin wrote: > On 2011-11-17 21:43+0100 Hendrik Sattler wrote: > > Am Donnerstag, 17. November 2011, 21:38:20 schrieb Hendrik Sattler: > >> Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf: > >>> Let's say package Foo (unrelated to KDE, and unrelated to cmake) has > >>> been ported from UNIX to Windows, and installs a pkgconfig file. > >>> This pkgconfig file is generated at the time when the binary package > >>> for Foo is generated. > >>> > >>> Now a user downloads and installs the binary package of Foo, along with > >>> the included pkgconfig file, which contains the install path from build > >>> time. But the user can now decide where he will install this binary > >>> package. This may differ from what is recorded in the pkgconfig file in > >>> the binary package of Foo. > >>> So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", > >>> but the user decides to install it to "D:/MyStuff/", so the include > >>> dir would be "D:/MyStuff/include". > >>> > >>> > >>> Now cmake comes into play. > >>> Let's say there is a project Bar, which uses Foo, so it does > >>> find_package(Foo). > >>> > >>> Now FindFoo.cmake uses pkgconfig: > >>> > >>> find_package(PkgConfig) > >>> pkg_check_modules(Foo ...) > >>> > >>> Now this will report C:/Foo/include (because this is what the > >>> pkgconfig-file contains), instead of D:/MyStuff/include, where the user > >>> decided to install it. > >> > >> No. Pkg-config should derive the prefix variable from the location of > >> the .pc file. According to documentation, it does this on Windows, so > >> it should report D:/MyStuff/include > > > > See http://cgit.freedesktop.org/pkg-config/tree/parse.c#n1136 > > Thanks, Hendrik for reminding me of that pkg-config feature. > I haven't looked at that URL in any detail, but your summary jibes > with the man page for pkg-config which states the following: > > WINDOWS SPECIALITIES > If a .pc file is found in a directory that matches the usual > conven‐ tions (i.e., ends with \lib\pkgconfig or \share\pkgconfig), the > prefix for that package is assumed to be the grandparent of the > directory where the file was found, and the prefix variable is > overridden for that file accordingly. > > If the value of a variable in a .pc file begins with the original, > non- overridden, value of the prefix variable, then the overridden value > of prefix is used instead. > > So the explanation of why pkg-config works fine for the GTK+ stack of > libraries is much simpler than I thought. The GTK+ *.pc files are > installed in a relative location within the install tree that matches > the standard conventions. So the ~10 different prefix variables for > the ~30 *.pc files are completely overridden in that case to > correspond exactly to the up-to-date special install location chosen > by the user at binary installation time. > > So everything works properly for pkg-config for the Windows case so > long as the binary package in question installs the *.pc files in the > right relative location in the install tree. That standard is > really easy for any software binary distribution to follow. So if any > windows binary package is broken this way (remember nobody has given > specifics of even one such broken package yet), it should be > incredibly easy to fix. > > It concerns me that some posts in this thread took the assertion that > pkg-config is systematically broken for Windows as the Gospel truth > without investigating that assertion any further. > > That assertion has now been proved to be a myth by my prior > investigation showing pkg-config works fine to find compile and link > information for 33 GTK+ libraries installed in a non-standard location > for a Windows platform (Wine). Furthermore, the man page section for > pkg-config explains the simple reason why that works which even more > strongly answers the assertion.
Agreed. The problems that some accuse pkg-config on windows don't actually exist. At the risk of repeating myself I will refute a pair of arguments that have already been discussed on the mailing lists kde-windows and kde-build system: http://www.mail-archive.com/[email protected]/msg06686.html http://www.mail-archive.com/[email protected]/msg03567.html * Relative prefixes: pkg-config in Windows implements a mechanism to support relative prefixes. To enable this mechanism, you need to reference in the .pc files all directories as relative to a ${prefix} variable. An example of well-built windows packages installing pkg-config files which work in any prefix and any compiler are found in the gtk.org page for Windows: http://www.gtk.org/download/win32.php * GCC compiler and linker specific flags like -I, -L and -l, which often appear in the pkg-config .pc specifications. They will not present any problem when using other compilers such as MSVC, since the macro "FindPkgConfig.cmake" interprets and/or ignores them properly. In short: pkg-config is not an obstacle for supporting multiple compilers / tool chains. I've been using the pair CMake/pkg-config in my own projects without problems, and promoting them in projects of all kinds for years. As an example, Windows users (and Mac/Linux users) of FluidSynth are quite happy with CMake: http://sourceforge.net/apps/trac/fluidsynth/wiki/BuildingWithCMake Regards, Pedro -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
