This is every make system I know of, and I’ll keep updating this. My terminology is that a make system can do dependencies and generate code (object files, binaries, arbitrary tool output); development environments typically sit on top of make systems but include editing and debugging; and build systems offer scheduling, multi-machine control, cross-platform in a single build, reporting/logging, and packaging/distribution.
This needs some sort of organization; I’ll probably do both a family tree, and alphabetical.
Make is written in C.
Perhaps the original make utility, written in 1976 and available with all Unix systems. There are two variants that deserve to be called make; POSIX make, the standardized version from IEEE Std 1003.1, and GNU make, which is the defacto standard. Wikipedia has links to useful information: http://en.wikipedia.org/wiki/Make_(software). It’s more likely that you have GNU make than POSIX make. The vast majority of open-source projects to date come with make files.
make is typically used only in conjunction with building Unix programs, and Mac programs that stick to POSIX features. make is also often used in conjunction with a configure program to generate a platform-specific or configuration-specific makefile, and autoconf is the most widely used such system.
There are a number of make-compatible variants.
- Microsoft’s nmake is a subset, and sees little modern use.
- Android uses GNU make but passes the android.mk and application.mk files to multiple phases of the build process.
Autotools is written in C.
While listed separately (because it sits on top of make), it is used in conjunction with make. A lot of Unix software in the 1970s through 1990s was build with Autotools. However, it’s really not recommended for anyone any more, it is very arcane, very slow, and very tied to a specific set of Unix toolchains. For example, KDE switched from Autotools to CMake.
Don’t use Autotools/Autoconf. Just don’t.
http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx. msbuild is probably written in C++.
msbuild is the build system for Visual Studio starting with Visual Studio 2005. The msbuild engine can directly consume .vcproj/.vcxproj files. Most Windows-only software is built with msbuild.
https://developer.apple.com/technologies/tools/. XCode is (presumably) written in Objective-C++.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/0-Introduction/introduction.html. XCode the IDE has an embeded make system that is available through the xcodebuild command-line tool, or directly from the IDE. Tragically, there is very little direct documentation on it, as compared to msbuild. See http://www.objc.io/issue-6/build-process.html for a simple overview.
http://www.scons.org/. SCons is written in Python.
SCons is a fairly cross-platform make system, in that a single SConstruct can be used to build on multiple platforms. It hasn’t seen much development in years, however. It would be nice if it doesn’t decay to uselessness, because it’s the only serious cross-platform make system available. It supports Windows and Mac, and a large varienty of Unix systems. SCons has configuration built in, it does not use a separate configuration system.
http://www.cmake.org/. CMake is written in C++.
CMake isn’t a make system on its own. Instead, it generates projects to be used in other make systems; its main clients are msbuild, XCode and make. It supports Windows and Mac, and some Unix systems.
http://martine.github.io/ninja/. Ninja is similar to make in philosophy. It was written by a Chrome engineer, and is supposedly replacing other make systems used by Chrome. Ninja is also not usually used as a standalone make system, but in conjunction with other make systems (e.g. CMake can generate Ninja makefiles). In fact, Ninja files are usually generated by something else, since they are not particularly convenient to write by hand. Also, from the author, Ninja is based on what he thought Tup did, but without the parts he disliked.
Stuff to read:
https://code.google.com/p/gyp/. Supposedly, gyp was written in reaction to the Chromium team’s problems with SCons.
Stuff to read:
http://gittup.org/tup/. Tup is a new project notable for its sense of grandiose humor, and its focus on performance. The http://gittup.org/tup/tup_vs_mordor.html page is well worth reading for anyone, not just for more Tup information. Tup is a dependency system, so it would be interesting to see what a complex code+data build looks like in Tup.
http://industriousone.com/premake. Premake is written in C and Lua. It is like CMake in that it generates makefiles for other build systems, it’s not a make on its own.
https://code.google.com/p/waf/. waf is written in Python.
This was originally a fork of SCons, but it can be considered to be a completely new project by this point. Also see http://docs.waf.googlecode.com/git/book_17/single.html.
https://code.google.com/p/fabricate/. Fabricate is written in Python.
Fabricate is interesting in that it has no explicit dependency declarations; it discovers them by watching filesystem operations. It’s essentially a build script that memoizes itself. That said, it only works on a few platforms, and is somewhat fragile because filesystem watching is not perfectly reliable on any system (it’s typically a bolt-on, or a system that is allowed to drop events when overloaded).
http://hackage.haskell.org/package/shake. Shake is a Haskell library for writing build systems.
https://github.com/apenwarr/redo. Currently written in Python, although the author stated he wants to re-implement it in C. It also really only works on Unix systems.
This is a cleanroom re-implementation of Daniel J. Bernstein’s (unreleased?) redo project; this is a make successor, intended to fix make’s inherent flaws.
https://github.com/da-x/crumb. It looks like this only runs on Unix.
This is not really a make system, but a tool that instruments filesystem calls to determine dependencies, and is intended for use in build systems, providing equivalent functionality to Fabricate.
https://code.google.com/p/badgerconfig/. This is written in Python.
This looks like just a Visual Studio project generator.
http://rake.rubyforge.org/. Rake is written in Ruby.
This is “Ruby Make”, although the makefiles use Ruby syntax.
http://omake.metaprl.org/index.html. OMake is written in OCaml.
While OMake uses the syntax of make, it isn’t really a make dropin because it extends make substantially.
https://github.com/felix-lang/fbuild. FBuild is written in Python 3.
This seems like yet another build system inspired by the decline of SCons.
http://srp.github.io/mem/. Mem is written in Python.
Mem works via instrumentation and memoization.
http://www.perforce.com/resources/documentation/jam. Jam is written in C.
Jam’s makefiles are derived from the syntax of Make, although it is not make compatible. It has been around for a long time, and is fairly well documented. But it’s make, and suffers from the same limitations and has the same problems.
FTJam (FreeType Jam).
http://freetype.sourceforge.net/jam/. FTJam is written in C.
FTJam is a slight enhancement of the original Perforce Jam.
BJam (Boost Jam)
http://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/index.html. Boost Jam is written in C++.
It was derived from FTJam, which in turn was derived from Perforce’s original Jam.
http://www.boost.org/boost-build2/. This is written in C++.
I think this replaced the use of Jam by the Boost team. I don’t know if anyone else uses Boost.Build. It also appears to be dead – there was a plan in 2007 to reimplement most of it in Python, but it looks like that was never started.
http://retropaganda.info/~bohan/work/psycle/branches/bohan/wonderbuild/wonderbuild/README, or http://sourceforge.net/p/psycle/code/HEAD/tree/trunk/build-systems/wonderbuild/wonderbuild/. Wonderbuild is written in Python.
Wonderbuild appears to have been written for the Psycle Modular Music Creation Studio project. A perhaps biased benchmark shows it as faster than most other make systems – http://retropaganda.info/~bohan/work/psycle/branches/bohan/wonderbuild/benchmarks/time.xml. It is not documented except by reading through the source code.