Trouble with glib2, pkg-config and cmake under Debian

[Alexander Neundorf]

On Tuesday 21 August 2007 11:16, Tobias Koenig wrote:
> Hi,
>
> 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.
>
> 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.
>
> So where is the bug? 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?

You are using UsePkgConfig.cmake, right ?
Please take a look at FindPkgConfig.cmake, which is much more advanced and 
will probably handle things better. Maybe this already solves the problem.

Beside that, I don't know why the pkgconfig file doesn't put all include dirs 
in the includedir variable.

You could also simply extend the cmake module to also check for glibconfig.h 
in appropriate directories, e.g. if the include dir 
is /usr/include/glib-2.0/, use GET_FILENAME_COMPONENT(NAME) to get 
the "glib-2.0" part, then twice GET_FILENAME_COMPONENT(PATH) so you get to 
the install prefix ("/usr"), and append lib/ to that. Use the glib-2.0 as 
PATH_SUFFIXES and add the lib/ path as additional path to the FIND_PATH() 
call.


The problem with pkgconfig is that it just returns strings which are 
appropriate for including them directly in the command for the compiler 
invocation ("-I/usr/include -DWHATEVER "), same for libs.
Now cmake is more advanced than that and actually prefers to know how it calls 
the compiler. I.e. it keeps a list of current include directories (as opposed 
to a string which will be inserted into the compiler command whatever it is) 
and it prefers to know exactly which libraries you want to link to something, 
i.e. with the complete full path.
Without that (e.g. if you simply get "-L/usr/lib -L/usr/lib/foo -lblub -lfoo") 
cmake would need to parse that string and try to detect which libraries are 
meant with this. It needs the full path for the libraries to sort the link 
directories correctly so you get the libs you want. It needs to know what 
include directories are so the dependency scanning works, it can eliminate 
duplicate include dirs and it can sort the include dirs correctly (project 
first, then the rest). All that is not possible with the approach taken by 
pkgconfig. It is too "simplistic", you can do gcc `pkg-config --cflags` 
file.c, but this is no good format to get the required information into 
another tool, be it cmake or any other buildsystem.
Add to that the fact that pkgconfig isn't available on many platforms by 
default (Windows, commercial Unixes, QNX, ...) and that the information it 
returns is not compiler independent, since it returns the flags just for that 
one compiler.

Bye
Alex