At my day job I work on a large C++/Java project. The project is really huge ~700K files. We use GNU Make and as you might suspect it is pain to build the project. Especially it is pain to rebuild it incrementally. Even if I change a small C++/Java file it takes ~10 minutes to recompile the project. A lot of time Make spends in its own internals – it tries to parse the Makefiles hell, it tries to sats() all files, it constructs full dependency graph and then rebuild it.
I am not very satisfied with our build system. Compare to other Makefile based projects it is fine, but we need something better. And I think many project in the corporate word have the same issue. http://gamesfromwithin.com/the-quest-for-the-perfect-build-system http://gamesfromwithin.com/the-quest-for-the-perfect-build-system-part-2
I started researching this question some time ago and I was surprised how many build tools besides Make/Automake exists out there. Let me describe just few of them:
- Autotools. It is de-facto standard for open-source projects. Old and portable across nearly all UNIX platforms. Many people hate it with passion because of its weird m4 language and unreadable output files.
- Scons. Written in Python. It uses Python program for build description. Unfortunately it is not scalable. KDE tried scons but then gave up and moved to CMake. Real-world usages: MongoDB.
- Waf. A fork of SCons optimized for speed. It also uses Python for build scripts. Who uses: Samba.
- CMake. IMHO the most widely used build tool outside of Make/Autotools. It generates Makefiles that you need to run later. Large and active community. It uses ugly custom-made language for macroses, it looks like BASIC. Honestly, I am not very impressed with its internals. Who uses: KDE.
- Premake. It tries to fix CMake script language by using Lua language instead. It also generates Makefiles that you need to run with Make. Activity is quite low.
- Tup. A tiny build tool. Claimed to be fast for incremental build. When I say fast i mean really fast. It uses inotify daemon to find changed files. Instead of keeping dependency graph in memory the tool stores it to SQLite database. According to tup documentation build time depends on number of files changed, not the project size.
Main sell point of all tools (except the last one) is a new syntax for build files. But they do not solve my problem – slow incremental builds. So I played with Tup a little bit more. There is a Linux distributive called gittup that uses this build tool. I tried to build/rebuild this Linux distro and honestly I am impressed how well Tup handles it.
I spent about a hour and converted LLVM project to tup. This was not difficult at all. Tupfile syntax is dead-simple, very similar to Make. Incremental build are fast, inotify monitor also works great.
So I declare Tup is my new toy for the next couple of weeks. And maybe some day I’ll try to convert my project to tup. Who knows.
Random stuff 