I’ve tried a bunch of new build systems like Waf and Scons too. Finally though, I’ve settled on cmake. Quite simply, it’s really nice. It works on all the major platforms, and it’s easy to use (has optional graphical configuration screens too, and works great under Windows).

I don’t think having to install cmake is some kind of onerous requirement on someone who wants to compile software on their system. I’d rather type “apt-get install cmake” than deal with some kind assembled from matchsticks system like autotools is, or this new gmake based one may be.

Besides, gnu make isn’t installed on that many platforms out of the box. In particular a Windows box/Visual Studio developer almost definately doesn’t have it installed. Installing cmake on windows is a 2 click install there, too. Although I’m primarily a Linux developer, using the same build system (one that works with Visual Studio directly) is a god send.

Lets not reinvent the wheel, lets just all use cmake and be happy, like those KDE guys

However, I think the only tool which can succeed is one which does not impose any requirements on the system on which the program is built. It’s OK to impose requirements on developers, but it’s not OK to impose them on people who build the source code. That is why the autotools have been successful: they do not impose any requirements.

As far as I can tell, cmake does impose a requirement: the system on which the program is built must have cmake installed.

http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/pkgsrc/pkgtools/autoswc/

With some manual changes it could be made to work outside of pkgsrc.

It does exactly that: generate a system-wide configuration cache for autoconf scripts so that you can add to it some tests, run them once and later reuse their results automatically. Speeds things up quite a bit in old machines.

The problem that autoconf has had with system-wide information in the past is that some tests are compiler dependent or even compiler-option dependent. Also of course when you update the OS the test results may change. These are not insoluble problems, but they are the reasons that autoconf generally does not use a system-wide cache file.

First, because you see this design pattern all over Unix, where single config files are replaced by multiple files in a foo.d directory. E.g. init.d, and crontab.d. Second, because then, a file need only include the config.d/whatever.h file it depends upon. Then, since every whatever.h has its own timestamp, when you change whatever.h, only those files which depend upon it need to be rebuilt.

Also, what about having a single directory which holds system-wide information? Run the tests, do the discernment once, and then it becomes available to all autotools. Dare I suggest /var/autotools/?