On 21.08.07 17:16:20, Tobias Koenig wrote:
> there is a problem with compiling glib2 dependend software with current
> Debian unstable and cmake.
> 
> Let me explain the problem a bit closer.
> 
> The current libglib2.0-dev package contains nearly all header files
> under /usr/include/glib-2.0/ but the file glibconfig.h is located under
> /usr/lib/glib-2.0/include. Unfortunately, some header files from
> /usr/include/glib-2.0/ include the glibconfig.h by '#include <glibconfig.h>'.
> 
> So when you want to compile your software you have to add both path
> /usr/include/glib-2.0 _and_ /usr/lib/glib-2.0/include to the -I flag.

Thats a glib-packaging bug in Debian, they obviously don't move that
header but they should as headers don't belong under /usr/lib.

> Now pkg-config and cmakes enter the scene: The shipped glib-2.0.pc file
> contains the correct 'cflags' variable, which includes both pathes,
> however the 'includedir' variable contains only the /usr/include path...
> 
> Our FindGLIB2.cmake module calls pkgconfig and queries for the
> 'includedir' variable instead of following the 'cflags' suggestion.
> 
> => the -I/usr/lib/glib-2.0/include is missing and the software doesn't
> compile.

I wasn't aware that KDE modules use glib, interesting...

> So where is the bug?

see above: The debian package.

> Is it possible to define multiple pathes in the
> 'includedir' variable? Would cmake be able to handle multiple pathes
> there? Should FindGLIB2.cmake use the 'cflags' variable instead of the
> 'includedir'? Shall we ask the Debian maintainer to place the
> glibconfig.h to /usr/include?

The last thing is the right thing to do.

Andreas

-- 
You feel a whole lot more like you do now than you did when you used to.