Question wrt KDE not depending on pkg-config (was Re: Initial support for kde_projects.xml in kdesrc-build)

[Alexander Neundorf]

Hi Raphael,

On Wednesday 02 February 2011, Raphael Kubo da Costa wrote:
> Alexander Neundorf <neundorf at kde.org> writes:
> > On Wednesday 02 February 2011, Michael Pyne wrote:
> > ...
> >
> >> e.g. worrying about environment variables like PKG_CONFIG_PATH is no
> >> idle claim (kdesrc-build sets that as well), along with PATH in order to
> >> pick up the right Qt version.
> >
> > Please try to use only CMAKE_PREFIX_PATH instead of setting PATH. I
> > recommend this to everybody.
> > I'd also suggest not to set PKG_CONFIG_PATH, at least not to directories
> > where KDE stuff is installed, this has to be found also without
> > pkgconfig.
>
> Sorry for deviating from the original purpose of the discussion (thus
> moving this to kde-buildsystem@).
>
> I question I've had for some time is why KDE's cmake files should not
> depend on pkg-config -- AFAIR, support for it on Windows used not to be
> good, but I've been told things have improved. Are there any other
> historical reasons for that?

* pkgconfig is strictly speaking not necessary, cmake can do what pkg-config 
does

* support for pkg-config is not on all platforms as good as on Linux

* it needs an additional env.variable to be set up correctly, so you have to 
remember to set CMAKE_PREFIX_PATH and PKG_CONFIG_PATH, although pkgconfig 
would not be necessary

* The way information is returned by pkg-config sucks. It is designed so that 
its output can be used directly in Makefiles in the compiler/linker command 
line. E.g "-L/some/where -L/some/other/place -lfoo -lbar". This is 
a) command line arguments specific for one compiler
b) not what cmake would like to have

E.g. for linking libraries, cmake does a lot. It analyzes where all the 
libraries are, collects an RPATH, orders the directories, detects if there 
are conflicts/ambiguities, e.g when linking to two libraries in two different 
directories, where each library exists in each directory. If you just hand 
the "-L/some/where -L/some/other/place -lfoo -lbar" to cmake, it cannot do 
all that. You have to be careful to get just the "foo" and "bar" parsed out 
of the string returned by pkgconfig, use these names for FIND_LIBRARY(), also 
parse the directories out of the string, use these as HINTS for 
FIND_LIBRARY(), and then use the results of the FIND_FOO() calls, which will 
have the full path, so cmake can handle them correctly.

* not sure about the behaviour wrt. crosscompiling. Different people say 
different things how it should be used there.



CMake has a more powerful alternative to this, which is not too different 
actually, by installing FooConfig.cmake files. These files contain just the 
information (e.g. the libraries which are needed), and no toolchain-specific 
syntax.
Downside is that this is currently hard to impossible to use from non-cmake 
buildsystems.

There are two ways to improve this:
* add a mode to cmake so it can be called similar to pkg-config
 e.g. something like "cmake --find_package JPEG --print 
JPEG_LIBRARIES --toolchain GNU", which internally does basically 
find_package(JPEG) and prints the specified variables, so the result can be 
used directly like that from pkg-config.

or/and:

* add a second file format for the FooConfig.cmake files, e.g. xml or json, so 
it can be easily used also by other tools, which don't have a cmake 
interpreter included.

Alex