Promising alternatives to make?

Build AutomationMakefile

Build 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:

http://www.cmake.org/

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:

  • AAP (Python)
  • SCons (Python)
  • Ant (Java, config in XML, pretty complex)

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

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionmike511View Question on Stackoverflow
Solution 1 - Build AutomationWaldWolfView Answer on Stackoverflow
Solution 2 - Build AutomationTodd GamblinView Answer on Stackoverflow
Solution 3 - Build Automationschettino72View Answer on Stackoverflow
Solution 4 - Build AutomationClinton DreisbachView Answer on Stackoverflow
Solution 5 - Build AutomationEric TalevichView Answer on Stackoverflow
Solution 6 - Build AutomationHotschkeView Answer on Stackoverflow
Solution 7 - Build AutomationtonyfischettiView Answer on Stackoverflow
Solution 8 - Build AutomationDaniel SpiewakView Answer on Stackoverflow
Solution 9 - Build AutomationAllan WindView Answer on Stackoverflow
Solution 10 - Build Automationdavetron5000View Answer on Stackoverflow
Solution 11 - Build Automationbu11d0zerView Answer on Stackoverflow
Solution 12 - Build AutomationRob WellsView Answer on Stackoverflow