Re: [Inkscape-devel] CMake status
Hi all,
by Aaron Spike-2 Dec 31, 2008; 01:12pm ...
If you have some CMake experience and would be willing to help us to perfect the CMake based build system for Inkscape, your help and patches would be much much appreciated. We would really benefit from someone with experience showing us best practices and helping us to make it work.
Of course, this invitation is open to everyone!
Aaron Spike
I'm the maintainer of the cmake based buildsystem for KDE4, which works on Linux, Solaris, FreeBSD, OSX and Windows both with MSVC and mingw.
While I don't have the time to actually help with your cmake stuff, I can answer questions and provide tips how to do things/where to look for stuff.
Alex
Alexander Neundorf wrote:
While I don't have the time to actually help with your cmake stuff, I can answer questions and provide tips how to do things/where to look for stuff.
Alex
I have a few basic questions:
1. Can CMake use the dependency information automatically generated during compilation by gcc? 2. How well does it integrate with gettext and pkg-config? 3. Is it possible to run programs compiled from source during the build process? Does this also work when cross-compiling?
Regards, Krzysztof Kosiński
On Sunday 04 January 2009, Krzysztof Kosiński wrote:
Alexander Neundorf wrote:
While I don't have the time to actually help with your cmake stuff, I can answer questions and provide tips how to do things/where to look for stuff.
Alex
I have a few basic questions:
- Can CMake use the dependency information automatically generated during
compilation by gcc?
No, it does the C/C++ dependency scanning automatically by itself. This works reliably.
- How well does it integrate with gettext and pkg-config?
pkg-config: in which direction ?
Installing pkgconfig-files: create a template foo.pc.in file, and configure it during cmake time to foo.pc, which can then be installed:
configure_file(foo.pc.in ${CMAKE_CURRENT_BINARY_DIR}/foo.pc) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/foo.pc DESTINATION lib/pkg-config )
For getting information: also works, but I don't recommend it, since pkg-config has issues. It is not always available on all systems (e.g. Windows, other UNIX variants) and the information returned by it is compiler specific (since it returns compiler switches) and kind-of bypasses cmake. So you have to be careful what you do. Usually you do the following to find some package, e.g. libxml2:
find_path(LIBXML2_INCLUDE_DIR libxml/xpath.h) find_library(LIBXML2_LIBRARY NAMES xml2)
This will search for the given libraries in a set of default directories appropriate for the current system. This is usually put into a Find<packagename>.cmake file, so you can simply do:
find_package(LibXml2 REQUIRED)
and cmake will search for it. (the REQUIRED makes sure cmake aborts if it wasn't found) On success, you use the results from that:
include_directories(${LIBXML2_INCLUDE_DIR}) ... add_executable(foo main.c) target_link_libraries(foo ${LIBXML2_LIBRARY})
Now if you use pkg-config, it gives you something like "-L/opt/foo/lib -lxml2". If this is just handed as it is to cmake, things may break. CMake takes care that when linking the linker will find the files the user intended to be linked. If you then add "-L/some/dir" to the linker command without cmake knowing that some link directory has been added, the linker may find something else. So, I recommend to use pkg-config optionally, and use only the directories it reports for the include dirs and library dirs as hints to the find_path()/find_library() calls above. A full example can be found here: http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindLibXml2.cmake?view...
- Is it possible to run programs compiled from source during the build
process?
Yes, no problem. We do that in KDE. Create the executable you need, and when you add rules which run it, add a dependency to that executable to them. This makes sure it is built first.
Does this also work when cross-compiling?
Yes, but this requires some special handling. Basically you first need to build a native version of the package, "export" the required tools, and then build the "cross" version of the package, which "imports" these tools. This is in use e.g. for building ParaView (http://www.paraview.org) for Crays.
Alex
participants (2)
-
Alexander Neundorf
-
Krzysztof Kosiński