Hi Raphael, On Wednesday 02 February 2011, Raphael Kubo da Costa wrote: > Alexander Neundorf <[email protected]> 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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
