Several of us now are able to successfully build Inkscape using cmake only. This is still relatively new, but we need to broaden this to everyone and make sure it works universally.

Do a 'make distclean' in your repo, update to latest bzr, and then:

$ cmake . $ make -j8

Hopefully this "just works". If not, read on for troubleshooting tips.

CMakeCache.txt is a listing of all configurable parameters and all computed values. For settables, you can force them via:

$ cmake -D<VARIABLE>=<VALUE>

If the build craps out during build or linking due to some missing bit or other, reviewing this file can indicate if it has misdetected an include or library path or whatnot.

CMakeList.txt is the top level build script, and generally the place to start for debugging problems. This also is where all configurable option parameters should be defined.

There is also a src/CMakeList.txt where the source files and header files are itemized. This also sets up rules for compiling and linking the executable and its libraries. Similar CMakeList.txt files are placed in other directories with source.

The CMakeScripts/ directory holds various helper functions. In this directory is a Modules subdirectory; this is where the logic is held that finds where various dependencies have their include and library files located. If you get errors about dependency headers not found during build, or during linking it can't find definitions of symbols then there could be an error in one of the Module Find*.cmake files.

CMakeScripts/DefineDependsandFlags.cmake is another important file; this is where the include path and library options are worked out. This file is essentially the "glue" that utilizes all the Modules, and propagates settings up to the top level script.

Beyond this, there is a wealth of cmake tips and examples on the web, so google will be your friend.

------------------------------------------------------------------------

So what development needs done?

While the cmake scripts work, they're a bit hacky and in need of some cleanup. Below is a laundry list. I'd encourage everyone to tackle a task or two, to get some cmake familiarity if nothing else. Once this work is all done, we can wrap up 0.92 and start the release process.

0. Cleanup definitions. In CMakeLists.txt there are a sequence of add_definitions() to set some environment variable definitions. Some of these may not be strictly needed, others could be moved to DefineDependsandFlags.cmake or to the respective Modules files.

1. Win32. Someone needs to try this against our supported win32 platforms, and fill in the missing logic that is specific to Win32.

2. More files. A lot is missing from the build... tests, man files, icons, locale. If it's not clear how to do the logic for this stuff, refer to another cmake-based project.

3. More Modules. In DefineDependsandFlags.cmake we just brute force several libraries (to pick a few examples: pangocairo, gthread, gomp, gslcblas...) These need to have proper Find<Library>.cmake scripts made. Generally these are pretty easy - just make it wrapperize pkgconfig. FindGtkSpell.cmake has a simple example. Google "cmake <library>" before you do any work though; sometimes someone has already done the logic and you can just copy.

4. Update Modules. Several of our modules were taken from cmake or elsewhere, a long time ago, and they've improved upstream since then. Snag newer versions, test, and add to our codebase. If we have local changes consider pushing those upstream.

5. Add more configuration options. Review what we offer in automake and make sure the equivalents are defined in CMakeLists.txt

6. Verify that uninstall works

7. Fix dist. In CMakeLists.txt it adds a custom svn command; this needs replaced with the equivalent bzr. And in general run 'make dist' and hack on it until it produces a proper tarball.

8. Identify other issues needing resolved. I notice FIXME's peppered here and there in various files. We'll want to tackle those or at least plan those tasks for later on.

Bryce