[CMake] [RFC] How to use pkg-config under Windows (... and OSX)?

[Alexander Neundorf]

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