102

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?

sorin
  • 161,544
  • 178
  • 535
  • 806
mike511
  • 1,685
  • 4
  • 16
  • 18
  • Won't the answer strongly depend on what the problem is? For the things I've tried to do with it, `make` is too simplistic. – reinierpost May 30 '12 at 07:20
  • 2
    Ruby Rake, CoffeeScript Cake, Python Scons, Java Ant/Maven, C# MSBuild, cross-platform CMake – FilBot3 Mar 14 '16 at 13:18
  • https://github.com/efimovalex/gomake – Alex Efimov Feb 16 '20 at 19:59
  • 1
    makefile is concise but a language on its own. I found it hard to debug. For python users there are many packages including `scons`, `luigi` (adapted to `shouldsee/luck`), `snakemake`, `waf`. There are many Java alternatives but this space is too small to write them all down. – shouldsee May 07 '20 at 10:45
  • 1
    I have not tried it yet, but https://github.com/casey/just sounds somewhat promising, "produces detailed error messages and avoids make’s idiosyncrasies, so debugging a justfile is easier and less surprising than debugging a makefile" – Dr. Jan-Philip Gehrcke Jul 21 '20 at 12:06

12 Answers12

36

check out SCons. For example Doom 3 and Blender make uses of it.

WaldWolf
  • 408
  • 3
  • 5
  • 1
    +1 for scons - conceptually similar enough to make that it's easy to get your head around but fixes some of the more badly broken things about make (such as handling of spaces in names). – Tom Aug 07 '14 at 02:51
  • 6
    SCons is Python 2 only, and after wasting days tring use SCons to compile a Python 3 version of a project written in Python and C++, I would advise people to stay away. Just use CMake, it's becoming standard for C++ at this point. Or if you want to use a Python-based build system, use [Meson](http://mesonbuild.com/). It runs fast and is being actively developed, which can't be said for SCons. – ostrokach Apr 15 '17 at 02:26
  • 6
    SCons has supported Python 3 since September 2017 (5 months after the above comment was written) and is Python 3 _only_ since version 4.0 (July 2020). – Michael Platings Oct 09 '20 at 09:18
  • Intriguing. Maybe the question is opinion-based, but the _votes_ on the answers provide the answer to the question. After a quick look, it looks like they nailed it. Oh yes, and `pip install scons` (from within a venv, of course) works like a charm. – Sam Jun 14 '21 at 03:01
27

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.

Todd Gamblin
  • 58,354
  • 15
  • 89
  • 96
  • 9
    Note that CMake still just generates makefiles. So if the problem with the implementation of GNU Make is that it can't do something you want, then CMake probably won't help you. Or autotools, for that matter. – Tom Aug 06 '14 at 03:28
  • 17
    CMake doesn't just generate makefiles. CMake can generate tons of different kinds of build files targeting tons of different compilers and platforms. Personally, I hate CMake because the config syntax is absolutely disgusting. – Taywee Sep 09 '16 at 21:25
24

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
schettino72
  • 2,990
  • 1
  • 28
  • 27
17

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)
Stéphane
  • 1,476
  • 3
  • 12
  • 12
Clinton Dreisbach
  • 7,732
  • 6
  • 29
  • 27
17

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.

Eric Talevich
  • 403
  • 3
  • 7
8

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.

tutejszy
  • 602
  • 7
  • 22
Hotschke
  • 9,402
  • 6
  • 46
  • 53
  • 4
    Notably `tup` depends on `fuse` and having the fuse kernel extension running, which as far as I'm concerned suggests the maintainers are nuts. `redo` hasn’t been updated in two years. I’d recommend `ninja`. – mxcl Apr 09 '13 at 15:16
5

I wrote a tool called sake that tried to make writing makefile-like things very easy to read and write.

tonyfischetti
  • 51
  • 1
  • 2
  • Interesting; but could you give us a little bit of information as to why you think sake is easier to “read and write”? We shouldn't have to install the project to see it it answers the question. – Dour High Arch Jan 08 '14 at 19:33
  • Sure! It sounded to me like part of the reason why the author of the original question was concerned about Make's implementation "overcomplicating the problem" was because of makefiles' obscure syntax. Sake uses files that are written in YAML and, from what I gather from other people's input, much simpler to read and write. – tonyfischetti Jan 08 '14 at 20:05
  • 1
    The fact that it uses YAML syntax should be part of the answer, perhaps with some elaboration on how YAML contrasts with `make` syntax. – Aaron Novstrup Jan 09 '14 at 18:36
  • I just used Sake for a build script and it's awesome. Thank you for writing it! – nooblar Dec 17 '15 at 15:50
  • Sake is amazingly simple. – Dan Apr 16 '18 at 16:18
4

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.

Daniel Spiewak
  • 54,515
  • 14
  • 108
  • 120
3

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

Tom
  • 7,269
  • 1
  • 42
  • 69
Allan Wind
  • 23,068
  • 5
  • 28
  • 38
  • I also prefer Make; it's bog standard, available everywhere, and there's a reasonable chance anyone new to the project will have used it before (or at least a better chance than anything else). But. I have a large code base (several thousand C++ source files) that is written for Visual C++ and which I am trying to get building under GCC on Linux. Make seemed the obvious choice for a build tool, and we've written a quick-and-dirty converter that parses vcxproj files and produces Makefiles. It was all great, until we tried it on a project with a space in the name. What are we supposed to do? – Tom Aug 06 '14 at 03:34
  • For the record, I've ended up with SCons. Since our converter was written in Python anyway, it was pretty easy to convert that to an SConscript instead. – Tom Aug 07 '14 at 02:50
  • @Tom where can we get a copy of vcxproj file parser? I too am working on a little project on Windows and would like to port to ubuntu. – Dan Apr 16 '18 at 16:14
  • @Maverick - my apologies, it was proprietary and I don't work there any more. I'm afraid recreating it is not trivial for complex build systems; while the VS workspace file is "just XML" and figuring out which source files to build and what options to apply is not too awful, you need to take build configurations (debug, release) into account and also that the solution and individual projects can also import arbitrary other msbuild files. Another option we considered was using msbuild to target GCC - and you might now find this easier as msbuild has matured a lot since then. – Tom Apr 24 '18 at 15:11
2

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.

davetron5000
  • 24,123
  • 11
  • 70
  • 98
1

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.

bu11d0zer
  • 433
  • 4
  • 13
0

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

Rob Wells
  • 36,220
  • 13
  • 81
  • 146
  • 1
    A simple answer to a complex question is not possible. Providing more focus in the question would help. – Rob Wells Mar 07 '18 at 09:10