[CMake] Finder repository

[Alan W. Irwin]

The point that should be emphasized is many libraries developed on Linux
export their compile and link information only using pkg-config so users of
those libraries _must_ deal with pkg-config or else reinvent the wheel.
So I felt Alex's comments below needed to be answered.

On 2008-05-26 22:36+0200 Alexander Neundorf wrote:

> First comment: pkg-config sucks (it prints unstructured, toolchain dependent
> information on stdout)
>

The parenthetical comment is fair, but the conclusion that "pkg-config
sucks" is not. You should expect some toolchain-dependent variation in
information reported since so many different toolchains are using
pkg-config!  In fact regardless of whether pkg-config is used to report the
results or not, most major libraries have idiosyncrasies in the compile or
link flags that must be used so it is up to individual build system
maintainers or CMake Find module maintainers to deal with that situation for
each library whether pkg-config is involved or not.  There is an old saying
"don't kill the messenger" which applies here.

> Second comment: pkg-config is not widespread outside of Linux (and maybe *BSD,
> don't know), so find modules should works also without pkgconfig

Remember we are generally talking about libraries developed on Linux where
it has only recently been possible to port them to windows (mostly thanks to
CMake although autotools does support MinGW/MSYS).  Since pkg-config
binaries are available for windows and since pkg-config does have facilities
for dealing with such things as the path conventions for windows, you may
find that use of pkg-config does spread to windows along with Linux
libraries that depend upon pkg-config to publish their compile/link
information.

One prime example of such spread to windows is libGTK+ and friends (as one
other has mentioned in this thread). Some of the PLplot drivers depend on
parts of the GTK+ stack of libraries.  I quote from one of our developers
(Werner Smekal) who recently reported to the PLplot devel list about how
simple it is to get those drivers to work on windows.

<QUOTE>
Cairo driver in Windows or using gtk+ for plplot on Windows
========================================================

1) Download the all-in-one bundle of the GTK+ stack including 3rd-party 
dependencies for windows:
http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.12/gtk+-bundle-2.12.9.zip
available from http://www.gtk.org/download-windows.html.

2) Expand the package to a directory, e.g. C:\Development\gtk

3) Set environment variables so that CMake can find pkf-config
set PKG_CONFIG_PATH=C:\Development\gtk\lib\pkgconfig
set PATH=C:\Development\gtk\bin;%PATH%

4) CMake will find pkg-config and all the libraries necessary to build the
pdfcairo, pscairo, pngcairo and svgcairo devices. xcairo will not be built
since the X-Headers are not present.

</QUOTE>

Note, Werner didn't have to do anything special, it all just worked the
first time with the combination of CMake and FindPkgConfig.cmake.
(BTW, with regard to FindPkgConfig.cmake I agree with others comment here
that its linker flag output should be converted from -L/-l form to absolute
pathname form.  Some while ago I introduced a macro into our PLplot build
system to do just that, but it would be nice if this were done automatically
by FindPkgConfig.cmake.)

So if pkg-config does not work properly for some library on windows and said
library only emits its required compile/link flags using pkg-config, you
could certainly do what Alex suggested which is (with a lot of
experimentation) figure out the required compile and link flags for the
library on windows for yourself.  However, I think a much better alternative
is help the developers of the library fix up their pkg-config results so
they work properly on windows.  If it can be done for gtk+ libraries it can
be done for any other library that is being ported from Linux to windows!

> Third comment: I think much better than the somewhat complicated
> FindPkgConfig.cmake would be a real cmake command which parses the pkgconfig
> files directly. This would be faster and it would be easier to get the
> information.

pkg-config essentially just delivers what is in the pkgconfig files (with
transformations to deal with dependencies and duplicates) so I
don't quite see the point of this advice.

>> That (widerspread use of pkg-config) would make many find modules obsolete.
>
> Let's say, it would make them simpler, some simple wrapping would still be
> needed.

I only partially agree with that.  As I said at the beginning, many major
libraries have idiosyncrasies in the compile/link flags that are required.
Currently, FindPkgConfig.cmake returns those idiosyncratic flags in
<XPREFIX>_CFLAGS_OTHER and <XPREFIX>_LDFLAGS_OTHER corresponding to the
--cflags-only-other and --libs-only-other pkg-config options.  For some
libraries some extra special processing might be needed to deal with those
flags so that a FIND module wrapper for the pkg_check_modules macro (which
appears in FindPkgConfig.cmake) would be necessary.  But for many libraries
you could use the pkg_check_modules macro directly and simply pass the
special flags to the compiler and linker using the COMPILE_FLAGS LINK_FLAGS
target property without any further processing being required.

Alex, I don't want to get into a flame war about pkg-config.  However, your
comments certainly did not agree with my personal experience with pkg-config
on Linux and what I have read about pkg-config on windows (either in its
documentation or what a PLplot developer that I trust has reported about
using it on that platform for PLPlot without problems).  So I thought many
here might benefit from my answers to your remarks.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________