Wednesday, January 14, 2009

CMake

Instead of telling you about the purpose of this blog I'm going to write a note about my experiences with CMake.
I've been upset about not having a good cross platform tool for writing make files. Make files actually is a somewhat too specific description. Perhaps a better one is build configurations.

First of all, I prefer to develop in visual studio, I really need a visual studio project file to work with. Visual Studio projects is a source of problems themselves. Typically when introducing new library paths or other global changes I tend to forget to update all versions (Release, Debug, Release with symbols, ia32, x64, etc.) so after commiting my code, a co worker who works on a different configuration, or even worse in a different project file (we used to need both visual studio 2003 and 2005 to build for all platforms) ends up in a shitty situation. Add to this a separate build system based on make for Linux and Mac that needs to be updated.
You can always blame this kind of errors on sloppy coders, but the problem is really in the process. If there are things that's easy to get wrong, people will make errors so it's better to make things easier to get right.

My personal experience with setting up a build system that works properly on Windows, linux and mac with working dependency tracking is quite painful. The root of all evil in our situation is that you want no redundancy in the included files and settings for the projects. They should be specified in only one place. You also need quite much flexibility in platform specific file lists and compiler flags. The natural approach would is to have the same build system on all platforms with abilities to make platform specific exceptions. I've seen lots of programs that claims to be better than good old make, but CMake is the first I've found that lets me work in Visual Studio without pain and still supports linux and mac properly.

My first impression of CMake wasn't that good. It was quite obvious that the script language was not designed by Donald Knuth. It was built around some macro like constructions with poor type checking and global variables where you feed in your compiler options. Accidentially getting a character wrong in a global variable name means you silently define a new nonsense variable rather than changing the setting you wanted. This is really a pity. I definitely think the CMake developers should have built their system around python or some other decent scripting language rather than creating their own less than stellar language.

After playing around some more with it, it seems very much like a program that does what it's supposed to do. Perhaps not in the most fancy and extensible way, but it gets the job done. That's truely awesome, I've been looking for this program for ages!

The major change in how I will develop with this system is that adding new files, library dependencies is done in a separate configuration file instead using the gui in visual studio. Then you just regenerate the projects and all is fine. The added bonus is that this one change update all configurations and platforms. To make things more convenient, they actually have a dependency on the specification files in the generated visual studio projects so when you change the project definition it will trigger a rebuild of the visual studio project. It seems to work good for most situations but I've managed to make things wrong in a way where the old project file was ruined and no new one was generated. This meant I had fix the error and manually run CMake to get the project file generated properly.

We've run into lots of problems so far, but all of them has been possible to work around. I've noticed when googling about the problems we've had, many of them have been solved quite recently. I chose to think of this as a good thing. If there are serious problems they provide some kind of solution rather than letting the users know that they are doing things wrong.

So far I've only been using it in Windows and it seems to do good. I've got it to use precompiled headers, build dll's, generate projects for both x64 and ia32. Soon, I'll see if the system pass the final tests, Linux and Mac.

2 comments:

  1. Have you tried SCons? It supposed to do pretty much what CMake/autotool does but it is entirerly written in python, and all config scripts are written in python as well.

    http://www.scons.org/

    ReplyDelete
  2. I did try it, but I didn't manage it to accept any path to cl.exe (the microsoft c++ compiler) despite an hour of environment massaging and googling and reading of documentation!
    They actually had a great post on the subject in their faq, but it just didn't work on my installation: http://www.scons.org/wiki/FrequentlyAskedQuestions#shell_env
    The thing I'm worried about is that it's not (as far as I know) generate visual c++ project files but uses make-file projects where I have to update the file lists in the projects independently functions like "find in files" or visual assists may not work as good if the vcproj files aren't containing the same files as the build system sees.
    Feel free to prove me wrong about this :)

    ReplyDelete