Dear GNU Autohell…
…could you please die?
In all seriousness, I don’t understand why in our age of cross-platform considerations, distribution packages, scripting languages and refactoring, so much Linux software still uses a stone-age build system.
I could list the advantages of CMake over GNU autohell… sorry, autotools for hours. I’ll just list the ones I submitted to the gtkpod developer who argued about its advantages, after I wrote a full CMake replacement for its autotools-based build system in one day.
- autotools only generate makefiles; cmake can generate makefiles, project files for various IDEs, and has (from my experience) better support for hooking into IDEs in the first place.
- There is only one command to learn to generate makefiles, regenerate the build system after making changes, etc. No need for autogen.sh.
- cmake is well-documented and easily extensible. For nearly every dependency, you can either find the way to hook it in the base bundle, or find an existing project that has a .cmake file for it. And it’s easy to write new ones.
- Strict checking of behavior between versions, compared to the constant problems with behavior mismatches depending on which versions of autotools were used to generate the configure script.
- All configuration is in one place (but easily splittable into included files), rather than all throughout the source tree in various .am and .in files.
- No difference in the steps to build from the VCS (which has no configure script) or tarball.
- Includes only the files with relevant configuration and nothing else. autotools installs lots of additional files used in configuration and building, and while it allows one to build without autotools installed, cmake is a single binary available as a package in all major distributions.
- Arguably more concise, intuitive and easy to learn. This is subjective, but compare the new CMakeLists.txt for gtkpod with its own configure.in and tell me which one you consider more concise and intuitive.
- Faster, since it, again, only checks for dependencies directly relevant to the build, and caches the results.
- Supports out-of-source builds. Cleaning up is as simple as deleting the build directory.
The only drawback is that cmake needs to be installed to build the software from the source tarball (autotools don’t even have this advantage for VCS builds). This may have mattered ten years ago, but not in modern desktop systems. Building from source (including installing all dependencies besides cmake) is not a task for the typical end user to begin with – they are expected to use distribution packages. And for package maintainers, cmake is a blessing – very customizable and patchable. I say that as an Ubuntu developer. :)
I had a dev use it for one of the projects I participate in and oh my god what a damn pita. Debugging it is so hard when a certain module isn’t found. It’ll randomly fail on windows or mac or linux and work on windows. Argh.
Not saying that autotools is tons better, but that solution is far from perfect. Personally, I’m slowly getting by with waf…
I have to agree with the previous comment, I use CMake for a project and it mostly work but when you need to do anything that isn’t included or develop a new module it’s a pain in the ass…
I think for the next project I manage I will try something WAF or SCons, they atleast as a very flexible base ( python and its standard library ).
nice post, kinda funny to start, but I got the point. To be honest I usually let my IDE do all the work, so I don’t often check to see which is better (I’m sorry :S). When I’m ready to delve into (real world) packaging I think I’ll give cmake a shot.
Some time ago, I’ve made a page with some notes about build system, and how many gnome/gtk+ projects are using them.
Take a look here if you are interested: http://live.gnome.org/JavierJardon/NewBuildSystem
I personally find autotools thoroughly incomprehensible, and the lack of backwards/forwards compatibility has pissed me off more than once. I think KDE’s use of cmake speaks volumes about its suitability.
As someone who’s encountered CMake, I can say that while autotools is ugly, i’d prefer it anyday to CMake. Not saying that autotools is great, just that if CMake wants to replace it, it needs a lot more work.
Automake:
1) It works everywhere. ** Autotools has spent a great amount of working ensuring that their tools run on all systems. I haven’t been as successful with CMake on this one.
2) Its standard, although this is lessening. ** Simply, more people use autotools. Not all dev systems have CMake, and pulling extra packages isn’t always seen as desirable. This isn’t the best of arguments, so I’ll stop.
3) It works. ** Missing dependencies? CMake? Good luck. It seems like it should handle this better being more intelligent, but everytime I’m using CMake and there are unsatisfied dependencies, it can be quite a PITA to figure out what they are.
Autoreconf has been around for a while now, it calls all the autotools in the proper manner.
* Strict checking of behavior between versions, compared to the constant problems with behavior mismatches depending on which versions of autotools were used to generate the configure script.I’m not exactly sure of what you’re saying here. The whole point of the autotools suite is that once it’s distributed, the user won’t have to generate anything, so there should be no way to get into a mismatch situation.
* All configuration is in one place (but easily splittable into included files), rather than all throughout the source tree in various .am and .in files.The autotools support top-of-tree configuration, this is the only mode I’ve used them in for years.
* No difference in the steps to build from the VCS (which has no configure script) or tarball.It is generally considered bad form to store generated files in VCS. Apart from the autoreconf step, the build is exactly the same.
* Includes only the files with relevant configuration and nothing else. autotools installs lots of additional files used in configuration and building, and while it allows one to build without autotools installed, cmake is a single binary available as a package in all major distributions.This is a really big advantage, a complete build system using LCM tools that are available on all unix systems, no matter how old and crufty.
* Faster, since it, again, only checks for dependencies directly relevant to the build, and caches the results.Autoconf supports caching of the test results, both within and between builds.
* Supports out-of-source builds. Cleaning up is as simple as deleting the build directory.All the autotools support out of tree builds.
Have you considered waf ( http://code.google.com/p/waf/ ).
Here’s a small benchmark of build tools – http://retropaganda.info/~bohan/work/sf/psycle/branches/bohan/wonderbuild/benchmarks/time.xml
Waf is quite nice and has a configure step (like autotools) and a build stage. You can set it up to not pollute source directories with intermediate files, etc. and the speed isnt half bad
@www.google.com/accounts/o8/id?id=AItOawnPjXhE4k3_KZhZ7fBW8PzQw2OhZSIEu78 (what a nick!)
* It is generally considered bad form to store generated files in VCS. Apart from the autoreconf step, the build is exactly the same.
What he means I guess is that with CMake there is no difference between a VCS checkout and a source tarball: – With autotools, you do not keep your Makefile.in or configure files in your VCS but include them in tarballs. – With CMake there is no such distinction, you just put the CMakeLists.txt in the VCS and in the tarballs. You do not store the generated Makefile in the VCS.
* All the autotools support out of tree builds.
I very often find autotool-based projects which do not support out of tree builds. Don’t know why. And even for projects that do, it still generates a few files in the source tree (the Makefile.in and the configure file itself).
She. And yes, that’s exactly what I meant.
Regarding waf: It looks promising. The wiki page looks disappointing with the overwhelming majority of red “to do” boxes, but I see that gtkpod is the only CMake-using program there (thanks to me, heh) and quite a few are now using waf. How is it with IDE support? Autotools integrate with Anjuta and CMake is supported in KDevelop and my personal favorite, Qt Creator.
Waf
+can build out of vcs
@“I say that as an Ubuntu developer. :)”@
To be precise, what do you do in Ubuntu?