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

[Alan W. Irwin]

Hi Alex:

On 2011-11-17 18:26+0100 Alexander Neundorf wrote:

> The [pkg-config Windows] issue is the following:
>
> 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".

That is an interesting example because that is exactly what I did with GTK+
for Windows on my Wine platform.  That is, I installed that beast in
its own special directory rather than in a standard Wine location.  So
let's try to investigate that case.

Here are some specific (line wrapped for mailing) pkg-config results I
get for a component of GTK+ under Wine using the MSYS version of bash
(a nice familiar working environment on Windows for someone like me
that is not that familiar with the platform).

bash.exe-3.1$ which pkg-config
/z/home/wine/gtkplus-2.22.1/bin/pkg-config.exe

bash.exe-3.1$ pkg-config --cflags pangocairo
-mms-bitfields 
-IZ:/home/wine/gtkplus-2.22.1/include/pango-1.0
-IZ:/home/wine/gtkplus-2.22.1/include/cairo 
-IZ:/home/wine/gtkplus-2.22.1/include/glib-2.0 
-IZ:/home/wine/gtkplus-2.22.1/lib/glib-2.0/include 
-IZ:/home/wine/gtkplus-2.22.1/include 
-IZ:/home/wine/gtkplus-2.22.1/include/freetype2
-IZ:/home/wine/gtkplus-2.22.1/include/libpng14

bash.exe-3.1$ ls Z:/home/wine/gtkplus-2.22.1/include/freetype2
freetype

That last "ls" command shows the header files are located in the
special install location I used for the GTK+ stack of libraries (with
prefix Z:/home/wine/gtkplus-2.22.1) for Windows. So this is a nice
example of working *.pc files on Windows that were installed in a
non-standard location.

Let's look at the pangocairo.pc file to see how this apparently works.
That file contains the following:

prefix=c:/devel/target/18e9007417f775a5bc83c60917e98632
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: Pango Cairo
Description: Cairo rendering support for Pango
Version: 1.28.3
Requires: pango cairo 
Libs: -L${libdir} -lpangocairo-1.0
Cflags: -I${includedir}/pango-1.0

That weird numerical file name for the prefix location appears to be
the key.  There are 33 *.pc files distributed with GTK+, but only 10
unique numerical prefixes.  So I assume those 10 prefixes correspond
to each independent software package within the GTK+ stack of
packages, and apparently some arrangement is made to update those 10
special file locations whenever (as in my case) the user specifies a
non-standard install location for the GTK+ stack.

So with care (as has apparently happened for the Windows binary
installer for the GTK+ stack of libraries) the Windows version of
pkg-config works fine for arbitrary binary package installation
locations chosen by the user.

I would claim that the GTK+ stack of libraries (which covers 33
different libraries from the above numbers) is the primary source of
pkg-config *.pc files for the Windows case. So the above good results
(assuming they are not just confined to the pangocairo subset of the
GTK+ stack that I have tested above) cover a huge amount of territory.

The only other pkg-config cases I am familiar with on the Windows
platform is libLASi (a library that produces nice PostScript results
for TrueType fonts) and PLplot itself.  However, in those cases only
source distributions are available so installation prefixes for the
*.pc files are automatically taken care of in the install part of
those builds. However, if we ever make a binary distribution of
libLASi or PLplot for Windows we will have to pay attention to this
issue.

There are several possibilities I can think of to explain the
difficulties the KDE developers have encountered with pkg-config
for binary packages on Windows.

I. There may be parts of KDE that configure *.pc pkg-config files now,
but where the Windows binary installer for that KDE component does not
properly update the prefix location pointed to by those *.pc files. 
It should be straightforward for KDE developers to fix such Windows
binary installer bugs following the trail pioneered by GTK+.

II. There may be parts of KDE that have a dependency on some external
non-GTK+ binary package that configures *.pc files but which has a
broken binary installer that does not update the prefix location
pointed to by those files.  That, of course, would be a bug that was
external to KDE, but at least the KDE developers could report it and
hope that those external packages eventually fix such installer bugs
following the good GTK+ example.

III. The KDE users that got into trouble may have simply copied GTK+
files around rather than properly using the binary installer for the
Windows version of GTK+. I think this is a fairly unlikely possibility
because other things than pkg-config would be clobbered by doing
something stupid like that.

Note that none of the issues above have anything to do with CMake
pkg-config support, but we have to discuss these issues here to
make sure they are all off-topic for CMake.

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
__________________________