Promising alternatives to make? [closed]

问题:

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?

回答1:

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

回答2:

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.

回答3:

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.

回答4:

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)

回答5:

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

回答6:

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

回答7:

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.

回答8:

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.

回答9:

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.

回答10:

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

回答11:

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

回答12:

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.