Alexander Neundorf neundorf at
Sun Sep 16 21:54:02 CEST 2007

On Sunday 02 September 2007 03:33, Thiago Macieira wrote:
> Allen Winter wrote:
> >So the current FindGLIB2.cmake works well enough for me now.
> Which is, unfortunately, not good enough. Glib2 could be installed
> in /opt, for instance.
> Listing all possibilities is not a reasonable solution to me. Can we start
> parsing --libs-only-I ?

Please have a look at FindPkgConfig.cmake, which is much more advanced than 
UsePkgConfig.cmake (which I wrote).
It may already do that.

> Removing pkg-config stuff is a bad idea when it's the only place to contain
> the information we need.
> For platforms that cannot/don't want to use pkg-config, I guess you should
> complain upstream. Options that I can see:
> 1) get those dependencies not to require extra information
> 2) get the extra information from somewhere else
> 3) get the platform to use pkg-config properly
> I'm so sorry that it doesn't work for everyone, but please don't shoot
> ourselves in the foot. pkg-config is there to stay and is well-supported on
> Linux. And it's the *official* procedure for finding certain dependencies.
> Use it.

Yes, it is there but I'm really not sure it will stay *the* official way to 
store this information under Linux (since it seems and I do my best that 
CMake is really picking up). It surely isn't the official procedure for 
finding certain dependencies if the using project is built with cmake.

More options:

2a) get non-cmake projects to install a file for cmake, looking like this:
SET(GLIB2_INCLUDE_DIRS /usr/lib/glib-2.0/include /usr/include/glib-2.0 ...)

2b) define a generic file format which contains this information, e.g. 
xml-based, so that this information can be processed by other tools (like 
cmake or anything else)

2c) would it help to parse the pkgconfig files directly be cmake, so that it 
doesn't have to execute pkgconfig and parse this output ?

3b) get all projects to switch to cmake ;-)


More information about the Kde-buildsystem mailing list