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. > > Alex, is it possible your KDE Windows developers who are objecting to > pkg-config tried a version from years ago when it did not have all > these Windows issues sorted out? I suggest you tell them to > investigate again using modern pkg-config. For example, they could > follow the experiment I tried using the all-in-one GTK+ 2.22.1 bundle > you can download from http://www.gtk.org/download/win32.php. If that > works (which it should do if the bundle is properly installed) or if > they use a modern binary version of pkg-config for Windows from that > same location, ask them to attempt to find any Windows binary package > that is broken with regard to pkg-config. There might be some of > those. But I very much doubt that is a systematic problem since it is > so straightforward (install the *.pc files in the correct relative > location in the install tree) to deal with the pkg-config Windows > issue the KDE Windows developers have been so concerned about.
Patrick, what are your experiences with this ? Alex -- 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
