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

Fri Nov 18 17:38:10 EST 2011

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/kde-buildsystem@kde.org/msg06686.html
http://www.mail-archive.com/kde-windows@kde.org/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