Cmake won against the incumbent, which was autotools. Still it's still far from being an enjoyable tool, whose experience is made even worse by its god-awful docs.
Personally, I vastly prefer autotools, both as a user and developer. When I got to the point I needed some kind of build system, I found autotools much easier to learn than cmake.
As user, I find the experience with autotools to be much nicer as well. For whatever reason, the interface just seems more intuitive. I mean, ./configure --help will tell you basically all you need to know. An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want.
I've run into more than one project that required a specific version of cmake, which as luck would have it, was not the version packaged with my distro. This leaves you either building another cmake first or finding a tool/library that isn't so persnickety.
Given the choice between trying a project that uses CMake or or autools, I'll choose the autotools based project every time.
> An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want.
sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project
> > An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want.
> sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project
The whole point of Autotools is that distributed source packages can be built by themselves, without requiring any part of Autotools to be installed. They build even on obscure systems that don't have any working version of Autotools.
If you have to install autoanything to build a random project that uses Autotools, either you are doing something wrong, or the project is using Autotools wrong, or maybe the Debian package is using Autotools wrong.
That said, I know what you mean. I've had to seek out a number of different versions of Autotools just to get some things to build. But that is because a lot of projects and/or distro packaging blatantly uses Autotools differently than it's was designed to be used. I don't think Autotools should be blamed for this.
The portability is a very nice feature of autotools, but that distinction between developer sources and distributed sources it was designed around isn't as clear cut or widespread as it used to be. If I start a new C/C++ project today, chances are I expect users to be building from the git repo or a snapshot of it, rather than a semi-cooked tarball.
(I don't know what build system I'd pick these days - probably just write the Makefiles by hand.)
> That said, I know what you mean. I've had to seek out a number of different versions of Autotools just to get some things to build. But that is because a lot of projects and/or distro packaging blatantly uses Autotools differently than it's was designed to be used. I don't think Autotools should be blamed for this.
yes, it absolutely should be. If a tool is misused, it's generally because it's hard to use correctly. In contrast, if I see a repo with a CMakeLists.txt I know that it's going to be a simple cmake && make.
> If a tool is misused, it's generally because it's hard to use correctly.
Citation needed.
Tools get misused all the time. If I use a flat bladed screw driver as a pry bar/chisel/whatever, that doesn't mean the flat bladed screw driver is hard to use.
