[CMake] Finder repository

[Alexander Neundorf]

On Tuesday 27 May 2008, you wrote:
> 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!  

I mean, e.g. for the include dirs, it returns "-I/some/dir -I/some/other/dir"
It would be much better if there was something  like
<include_dirs>
   <dir>/some/dir</dir>
   <dir>/some/other/dir</dir>
</include_dirs>
same for libraries etc. This wouldn't then depend on "-I" being the flag for 
include directories for the compiler.
So yes, pkg-config is better than nothing, but it is not perfect. 

> > 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

Not only. E.g. Qt, libjpeg, and others.

> 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.

Yes, that's nice.
Still the dependencies include more than strictly necessary (pkg-config) and 
he had to adjust PKG_CONFIG_PATH.

> (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.)

I agree too.

> > 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.

I think it would be easier to process the files directly in C++ code than to 
parse the stdout from a cmake script. Also sometimes the pkg-config files 
contain some flags in the wrong "section" (e.g. include dirs in C flags or 
something like that). By parsing them directly it should be possible to 
handle that better (just gather everything together and then figure out the  
include dirs, link libs and flags).

> >> 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

Or take e.g. kdevelop or any other IDE as example. In order to do proper code 
completion they have to know the include dirs. Parsing the stdout which 
contains "-I/some/dir" is not really nice. Having some nicely structured 
information would be better.

Alex