Joshua A. Andler-2 wrote:
Perhaps cmake support should be held off for that longer 0.49 cycle since it's a type of refactoring. I wouldn't be opposed to it for 0.48, but have no idea how far off it really is at this point.
CMake support needs to be substantially rewritten before it's usable, because the current work is incompatible with Linux and Mac. Windows linkers resolve back references between static libraries (e.g. libX.a can have references to libY.a and libY.a can have references to libX.a), while Linux linkers don't (no circular dependencies between .a files are allowed). Currently CMake tries to link one library per directory, which does not work because of circular dependencies.
Personally I don't like CMake because its syntax is weak (no boolean expressions in conditionals; nothing like Automake's += exists so I have to spell out a variable's name twice if I want to append something, e.g. SET(inkscape_sources ${inkscape_sources} some-file.cpp)), ugly and irregular (sometimes case-sensitive and sometimes not). Some of its built-in macros are apparently incompatible with C++.
SCons looks much nicer to me. It allows you to use the full power of Python for build scripts, but I have not used it much yet. Certainly the number of people who can read Python is much greater than the number which can read CMake macros, so more people could diagnose and fix build problems. Currently we suffer from the fact that Automake is somewhat arcane and adding new useful features to it (SVN revision in the About dialog for example) is a pain. It looks sufficiently capable, and it's used in commercial projects like Google Chrome and VMware. The downside is that it doesn't have native support for gettext internationalization.
Does anyone have strong opinions on build systems, or know some 'killer features' that could affect the choice?
Regards, Krzysztof Kosiński