Promising alternatives to make?
Build AutomationMakefileBuild Automation Problem Overview
I've been using make and makefiles for many many years, and although the concept is sound, the implementation has something to be desired.
Has anyone found any good alternatives to make that don't overcomplicate the problem?
Build Automation Solutions
Solution 1 - Build Automation
check out SCons. For example Doom 3 and Blender make uses of it.
Solution 2 - Build Automation
I have a lot of friends who swear by CMake for cross-platform development:
It's the build system used for VTK (among other things), which is a C++ library with cross-platform Python, Tcl, and Java bindings. I think it's probably the least complicated thing you'll find with that many capabilities.
You could always try the standard autotools. Automake files are pretty easy to put together if you're only running on Unix and if you stick to C/C++. Integration is more complicated, and autotools is far from the simplest system ever.
Solution 3 - Build Automation
doit is a python tool. It is based in the concepts of build-tools but more generic.
- you can define how a task/rule is up-to-date (not just checking timestamps, target files are not required)
- dependencies can be calculated dynamically by other tasks
- task's actions can be python functions or shell commands
Solution 4 - Build Automation
I recommend using Rake. It's the easiest tool I've found.
Other good tools I've used, though, if Ruby's not your thing, are:
Solution 5 - Build Automation
Some of the GNOME projects have been migrating to waf.
It's Python-based, like Scons, but also standalone -- so rather than require other developers to have your favorite build tool installed, you just copy the standalone build script into your project.
Solution 6 - Build Automation
Be aware of the ninja
build tool (v1.8.2 Sept 2017) which is influenced by tup
and redo
.
The build file generator cmake
(e.g. for Unix Makefiles, Visual Studio, XCode, Eclipse CDT, ...) can also generate ninja
build files since version 2.8.8 (April 2012) and, afaik, ninja
is now even the default build tool used by cmake
.
It is supposed to outperform the make
tool (better dependency tracking and is also parallelized).
cmake
is an already well-established tool. You can always choose later the build tool without modifying your configuration files. So if a better build is developed in the future which will be supported by cmake
you can switch to it conveniently.
Note that for c/c++ improving compilation time is sometimes limited because of headers included through the preprocessor (in particular when using header-only libs, for instance boost & eigen) which hopefully will be replaced by the proposal of modules (in a technical review of c++11 or eventually in c++1y). Check out this presentation for details on this issue.
Solution 7 - Build Automation
I wrote a tool called http://tonyfischetti.github.io/sake/">sake</a> that tried to make writing makefile-like things very easy to read and write.
Solution 8 - Build Automation
It sort of depends on what you're trying to do. If all you want is make-style target dependencies and command invocation, then Make is actually one of the better tools for the task. :-) Rake is very nice, but can be clumsy for some simple cases. Ant is of course verbosity city, but it has better support for building Java-like languages (Scala and Groovy included). Also, Ant is available everywhere. That's the main reason I use it. Because it works consistently on Windows, it's actually even more cross-platform than Make.
If you want dependency management for Java-like libraries, Maven is the canonical choice, but I personally like Buildr a lot better. It's faster and much easier to customize (it's based on Rake). Unfortunately, it isn't quite as ubiquitous as Maven just yet.
Solution 9 - Build Automation
I still prefer make after having considered a bunch of the alternatives. When you auto-generated dependencies either via the compiler or something like fastdep there is not much left to do. In particular I do not want my build script to be tied to the implementation language, and I don't like writing stuff in XML when more readable alternatives are available. A tool that expose a general purpose language has merit though, but yet another interpreted language does not (afaik). What is Wrong with Make? might appeal to your point of view about moving away from make.
/Allan
Solution 10 - Build Automation
Ruby's make system is called rake: <http://rake.rubyforge.org/>
Looks quite promising.
There's always Ant: <http://ant.apache.org>;, which I personally find horrendous. It's the de-facto standard for Java development, however.
Solution 11 - Build Automation
FlowTracer from RTDA is another good choice that I have seen used commercially in a large scale environment (tens of thousands of jobs): http://www.rtda.com/flowtracer-design-flow-infrastructure-software
It has a GUI which shows the dependency graph with color-coded boxes for jobs and ovals for files. When the number of jobs and files gets high, a GUI-based tool like FlowTracer is pretty much essential.
The initial setup cost is higher than Make. There's a learning curve for setting up your first flow using it. After that, it gets quicker.
Solution 12 - Build Automation
I'm not sure if you are asking the correct question here.
Are you after a simplified make? In which case, you need to get someone who is very familiar with make to create a series of (M|m)akefiles that will simplify your problem.
Or are you wanting to look at the underlying technology? Are we wanting to enforce a design-by-contract type architecture which is built in to, and enforced in, the code design? Or possibly, the language itself, e.g. Ada and its concept of specs (interfaces) and bodies (implementations)?
Which direction you are after will definitely affect the potential results of such a question?
Basically, new ways of building systems from only those components that have really changed versus adoption of new technologies that have such mechanisms built in by design.
Sorry it's not a direct answer. Just wanted to try and get you to evaluate which path you wanted to head down.
cheers,
Rob