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

[Alan W. Irwin]

Hi Alex:

On 2011-11-15 18:07+0100 Alexander Neundorf wrote:

> Hi,
>
> cmake ships with a FindPkgConfig.cmake file, which is used by some Find-
> modules.
> Also in KDE, we have quite a lot of Find-modules which use
> FindPkgConfig.cmake.
>
> Now, some of them put a
>
> if(UNIX)
>  find_package(PkgConfig)
> endif()
>
> around it, some use it on all platforms.
>
> In theory it works also on Windows, and also on OSX, so that this if() would
> not be necessary.
>
> But our (KDEs) Windows developer team says that even if pkg-config is found
> under Windows, and even if it reports something, they actively want to ignore
> it.
>
> The reason for this is that for those packages under Windows the user decides
> at install-time where the package will be installed, while the pc-files for
> pkg-config have been generated at build-time with the install directory the
> developer chose at build-time.
> This directory chosen by the developer and hardcoded into the pc-files and the
> actual install directory chosen by the user can very well be different.
>
> If this is the case, then pkg-config reports wrong include and wrong link
> directories, and the build will work worse than without pkg-config.
>
> Similar issues may exist under OSX, for libraries which are installed as a
> package where the user can decide at install time where to put them.
>
>
> So, I am looking for a, if possible, generic solution to his problem.
>
> Options I see:
>
> 1) exclude it from being used under Windows in the Find-modules:
> if(UNIX)
>  find_package(PkgConfig)
> endif()
>
> 2) completely exclude it under Windows by putting something like the following
> into FindPkgConfig.cmake:
> if(WIN32)
>  return()
> endif()
>
> 3) don't exclude it, but hope it reports good results (our Windows developers
> disagree)
>
> 4) add cache option whether pkg-config should be used under Windows, so
> something like the following would be in FindPkgConfig.cmake:
>
> if (NOT CMAKE_USE_PKGCONFIG_UNDER_WIN32)
>  return()
> endif()
>
>
> 5) something else...

The Linux (also Unix?) tradition is to allow some flexibility with
install location by allowing the user to specify at least the install
prefix at configuration (i.e. cmake) time.  For relative install
paths, CMake supports this idea with CMAKE_INSTALL_PREFIX.  For
absolute install paths, it is the responsibility of the developer of
the CMake-based build system to prefix the absolute install paths with
CMAKE_INSTALL_PREFIX. For example, that is the approach we take with
PLplot.

Anyhow, if the developer of a CMake-based build system has been
careful to support CMAKE_INSTALL_PREFIX (either with relative install
paths or absolute ones that have ${CMAKE_INSTALL_PREFIX} prefixed),
that generally gives users all the installation location control they
need.  For example, in PLplot all generated pkg-config files are
installed in an absolute location that is automatically prefixed by
${CMAKE_INSTALL_PREFIX}.

I don't completely understand the use case that you have described for
the KDE windows developers. If they just want their users to be able
to control the installation prefix, why don't they advise those users
to use CMAKE_INSTALL_PREFIX?

I assume the KDE windows developers do not want their users to be able
to specify arbitrary installation locations for every KDE file since
that would be nothing but a horrible mess.  Also, I assume that asking
Windows users to specify the install prefix at configuration time
(i.e., cmake time) rather than install time is not a huge burden.
Thus, I am only left with the speculation that somehow
CMAKE_INSTALL_PREFIX is currently not being supported by the KDE build
system. Is that the real issue here?

The CMAKE_INSTALL_PREFIX approach works fine for PLplot (including the
locations of our pkg-config support files) on Linux, Mac OS X, and
Windows.  In fact, one of our two alternative test systems for our
installed examples is based on make and pkg-config.  Furthermore, our
important "cairo" device driver (based on the pango/cairo subset of
the GTK+ library stack) requires the use of pkg-config. Both that
alternative test system and our cairo device driver works fine under
MinGW/MSYS (I have tested that myself under wine with a Windows
installation of GTK+ and a special value
for CMAKE_INSTALL_PREFIX).  Both of those PLplot components should
also work fine under Cygwin.  Therefore, I wouldn't want to lose that
pkg-config capability under Windows so I would strongly object to any
Windows pkg-config limitations that were built right into CMake.

Of course, if KDE developers want to drop pkg-config support for the
Windows case within the KDE build system, that is their prerogative.
However, as the PLplot CMake-based build system shows, that is
certainly not necessary.  Also such a step for the KDE build system
removes some useful value (the ability to link applications against
KDE libraries using pkg-config) from that build system for those using
MSYS or Cygwin.

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
__________________________