I call this “long-awaited” because I promised Donnie to write about this a few months ago, but I haven’t had time to work on it in quite a while. Since today it should be an holiday, yet I’m still working on a few things, I’m going to try filling the hole.
I have been criticising CMake quite a bit on my blog, and I have been trying with all my strength to show that autotools aren’t as bad as they are made appear since I think that is still the best build system framework we have available at the moment. But in all this, I’m afraid the wrong message was sent somehow, so I want to clear it up a bit.
First of all, CMake isn’t as bad as, say, scons or imake; it’s also not as bad as qmake under certain circumstances. I don’t think that CMake is bad in absolute; I just think it’s bad as an “universal” solution. Which I have to admit autotools are bad for too, to an extent. So let me explain what my problem is.
For Free Software for a long time the autotools framework was the almost de-facto standard for lots of packages; switching away from that to CMake just because “it’s cool” or it seems easier (it does seem easier, mostly because the autotools documentation and examples are full of particularly bad code), it’s not the right thing to do since it increases the work for packages, especially because for some things CMake isn’t yet particularly polished.
I blame KDE for the CMake tide not much because I don’t think it was the right choice for them, but rather because they seem to pinpoint the reasons to the change to autotools defects when they are, actually, making a pragmatic choice for a completely different reason: supporting Microsoft Visual C++ compiler. As I have already expressed more than a couple of time, the autotools-based buildsystem in KDE 3 is a real mess, a bastardised version of autotools. Blaming autotools in general for that mess is uncalled for.
It’s also not only about Windows support; you can build software under Windows with just autotools, if you use cygwin or msys with GCC, what you cannot do is building with Microsoft’s compiler. Since GCC objectively still lacks some features needed or highly desired under Windows, I can understand that some projects do need Microsoft’s compiler to work. I’m not sure how true that is for KDE, but that’s their choice to desire Microsoft’s compiler. And CMake allows them to do that. More power to them.
But in general, I’m very happy if a project whose build system is custom-made, or based on scons or imake, gets ported to CMake, even if not autotools, since that would mean having a somewhat standard build system, which is still better than the other options. And I’m totally fine if a project like libarchive gets dual build system to build on Unix and Windows with the “best” build system framework available on those systems.
Still, I think CMake has a few weak spots that should be taken care of sooner rather than later, and which are shared with autotools (which is what I usually point out when people say that it’s always and only better than autotools; while it’s actually making similar mistakes).
The first is the fact that they seem to have moved (or people claim they moved) from an actual build system solution to a “framework to build build systems” which is more or less what autoconf basically can be said to be and what scons always have been. This is particularly bad because it ensures that there is no standard way to build a package without actually having to check the definition files for that particular release: scons provides no standard options for flags handling, feature switching and similar; autotools can be messed up since different packages will use the same variable names for different meanings. If CMake were to provide just a framework, it’s have the same exact problem. I think somewhat this was supposed to be limited, from what I read when I tried to learn CMake, but the results now don’t seem to be as good.
The second problem is slightly tied to the one above, and relates to the “macro hell”. One of the worse issues with autoconf is that beside the set of macros provided with autotools itself, there are basically no standard macros. Sure there is the Autoconf Macro archive but even I fail at using it (had some problems before with the license handling, should probably try to use it again), and the result is that you end up copying forking and modifying the same macros over a series of projects. Some of the macros I wrote for xine are now used in lscube and also in PulseAudio .
CMake provides a set of modules to identify the presence of various libraries and other software packages; but instead of using it as an official repository for these macros, I’ve been told that they are “just examples” of how to write them. And some of them are very bad examples. I already ranted about the way the FindRuby module was broken and the issue was ignored until a KDE developer didn’t submit his version. Unfortunately there are still modules that are just as broken. The CMake developers should really look into avoiding the “macro hell” problem of autotools by integrating the idea of a macro archive with CMake itself, maybe having an official “CMake modules” package to install to the side to provide the package search macros, which can be updated independently from the actual CMake package.
I have lots of reserves about CMake, but I still think it’s a better alternative than many others. I also have quite a few problems with autotools, and I know they are far from perfect. Both build systems have their area of usefulness, I don’t think either can be an absolute replacement for the other, and that is probably my only problem with all this fuzz over CMake. Also, I do have an idea of what kind of buildsystem framework could hopefully replace both of them, and many other, but I still haven’t found anything that comes near it; I’ll leave that description for part two of this post, if I can find time.
There’s actually a pretty good reason to build with the Microsoft compilers. They link against the version-specific C Runtimes which is a supported scenario. Mingw links against the system C runtime msvcrt.dll which is no longer a supported scenario.Another reason is that, as far as I know, gdb doesn’t support the memory dump formats that Windows uses. So, instead of saying “send me your crash dump”, users of software built with mingw have to go through extra work to get a stack trace to the developers. This means less bugs are getting fixed.There are actually some other issues though that I want to tackle one day. One is that those version-specific C runtimes are side-by-side assemblies. The only supported way to install them is with a MSI and there is no way to build an MSI from a non-Windows system.I did notice recently that Autotools finally started handling spaces in paths which is a common thing on Windows systems. The sad thing is that the normal ways of getting Autotools on Windows is through Cygwin, Msys, or Unix Subsystem for Windows. All of them are still distributing old versions that don’t support the spaces in paths. The result is generating configure scripts that don’t run correctly.
As I said, GCC is still objectively lacking some features. I don’t doubt about that. Sincerely I prefer Codegear’s compiler to Microsoft’s bug that’s just taste I guess.
A very good article, this time is more clear your point of view about CMake and I agree with you on all the points, except the one about CMake Find* modules: they are not developed by CMake devels (only few of them and the core modules come from Kitware), but they comes from external contributors of the CMake project itselt; obiovusly the real problem here is the lack of a better QA/testing of the user-submitted contributions before to release them.p.p.s: CMake 2.6.x and 2.7.x (the ones that i’m using) have better, but not perfect, modules;p.p.p.s: you forgot another Autotools weakness: the lack of support for QNX, where they are heavily cannibalized to make them (badly) working on it. CMake works very well on QNX without any particular hackish (and the same sintax remain valid for all the OSs).
The modules I have been judging came with 2.6.3 which I have right now. And it really doesn’t matter whether the modules are written by Kitware or by community contributors, in either case they are not tackling one very huge issue that really could have been their killer application. Finding a perfect software is impossible, but covering up one of the biggest holes in autotools (the non-standardisation of macros) would have made them gain lots of points.As for QNX.. I never had the “pleasure” to try it; I guess the problem here is that you’re expecting autotools in general to act as a knowledge repository build system but that’s not the case if not for libtool. I don’t know to which extent libtool supports QNX, but autoconf is not supposed to support it in any way; it should rather just allow to discover the features. The big obstacle (the same that MSVC and BCC have) is that it expects a Unix-compatible syntax from the compiler, which works out for GNU’s, Sun’s and Intel’s compilers but not for many others.
Have you ever heard of Boost.Build? I guess it’s like CMake from what I’ve now gathered. I haven’t done a whole lot of advanced stuff with it, but it supports multiple compilers, and makes dependency handling really easy. Here’s one I’ve written: http://github.com/markuspel…I’ve been avoiding figuring out how to do more than the equivalent of ‘make’.
I agree, autotools are not as bad as they appear to be.Autotools are worse than they appear to be.It’s just that not enough people actually look at what exactly it does underthe hood—take all those endless useless checks which cannot be reduced evenwith minimal input files…
Largely nice points. But I want to correct two slight mistakes:”the autotools-based buildsystem in KDE 3 is a real mess”It may or may not be a mess, but it works without a problem for me. The KDE 4 build system however gave me a lot more headaches.I am sure that the KDE team will eventually make KDE 4 build process super-smooth, but for now the fact remains that – hack or not – the kde 3 build process was better than the KDE 4.Second error:You single out KDE but they are not alone in their critism of autotools. Take Rosegarden. They for a long time critisized that adding 100 lines just to check something in Autoconf Macros is a horrible solution.The fact is this:Cmake is not perfect.But Autoconf sucks.Btw dont forget libtool. Basically all autoconf stuff – on linux – requires libtool. This introduces more problems …oh man…. this is all so sad!
We just converted a whole slew of s/w over to CMake and after spending two months of dealing with the mess of issues with it, I am wishing I had never heard of the thing.For starters, the syntax is simply horrid. Maybe it is a “simple” syntax, but putting the parser’s needs above the users’ is silly. If simple syntax were the answer, then we’d all be programming in TCL for everything. Ugh. Give me a decent balance of power and syntactic sugar over this ugliness any day.Layers and layers of macros and impenetrable auto-generated makefiles scattered hither and yon make it nearly impossible to figure out why it is screwing up a build. You can replace 75% of its “power” with a well-designed set of GNU make rules and macros and it will be 200% easier to debug and run 50% faster.If often puts the onus on the user to specify the same thing multiple ways in order to get something to build correctly. Or it forces the user to do three steps in a particular order to accomplish a task that it could easily handle in a single error-proof step.The quality of configure/build tools that are being deployed out there by lemmings following the latest trend is staggeringly bad. CMake is just another example this.
Look at http://sourceforge.net/proj…It has a library-based approach for macros handling, it’s very small (about 1500 lines, with docs and tests included), it’s declarative nor imperative, it’s simple (after you installed NetBSD bmake and NetBSD mk-scripts…)
Really wish we could see part two where you describe what kind of build system could replace autotools and cmake.
So now it’s been five years. SCons and CMake have incremented their major version; Premake has gained some traction; Waf and Tup exist now…etc. I’d be really interested in your take on the current state of build systems, Autotools and otherwise.