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

[Alan W. Irwin]

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.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________