Recently I have played a bit with the Quantum GIS build system. Currently we use classical approach by using autotools: autoconf + automake + libtool. This build system is used in many programs with success. Originally it was designed to solve portability problems when using different flavours UNIX systems. With time it became very popular as it takes much of hard work off the developers.

However Autotools system has also issues. It's not easy for average developer to use or even create autoconf macros because they use M4 macro processor spiced with shell programming. These tools are quite complex and therefore a lot of tasks in maintenance of a project's build system's is nightmare for many developers. And finally it doesn't support Windows platform natively since it doesn't provide unix-like shell with some common tools like sed.

It's time to look for a better and more modern alternative. CMake is one such alternative, in recent time quite famous because KDE developers decided to switch to it for upcoming KDE4. Let's take a look on it.

CMake is a cross-platform make system. If you never heard about it you can read a bit about CMake and about its features on the project's page. I'm not going to put any examples here since there are some simple examples and examples of using Qt with CMake available. I'd like to be more Quantum GIS specific.

What major advantages CMake brings in comparison with current build system:

• configuration and build rules with simple and easy to learn syntax
• good support for building on Windows natively (with MinGW or MSVC)
• much faster make times
• output of 'make' command with colors :-)

I was quite surprised with the speed of building Quantum GIS codebase in comparison to Autotools. Results of my test compilation and installation are below. I used Lib_Refactoring branch in Linux environment. My computer has AMD Athlon XP 2500+ processor and 512 MB of memory. All times are in format minutes:seconds.

Quite a big difference, isn't it? The main reason of such great difference is the fact that CMake doesn't make use of libtool which likes to consume pretty much time because it's a huge shell script which is run many times during the building. For me, build time is quite important and nearly twice faster build time is a very good reason to use CMake. Hopefully we will not encounter any fatal problems in CMake that would make impossible to use it as default build system for next version (0.9) of Quantum GIS.