What GNU make substitute do you recommend?

Question

Imagine you're free to choose a tool like GNU make for a new C++ project. What would you choose? Are any usable substitutes out there?

It shall have/be

• a command line interface
• "easy" to understand ;)
• easy to set up for a default c++ project
• may support src/bin seperation as common for Java
• may not add too much dependencies to other software/libs
• platform independent (new)
• features:
  • build rules / templates like make but in an human readable way
  • recursively crawling directories and applying the rules if there is no other "Makefile"
  • configuration by exception

Note:

Nothing's wrong with GNU make. I just don't like its grammar, all the stuff that grows in the years and the silly recursive make problems. I'm using gmake for years now, but now I've the chance to switch to something new. So, I'll take the chance and asking the community. ;)

I thank all of you for your contribution!

Answer 1

Personally, I prefer just using Bash scripts.

Answer 2

SCons + swtoolkit

Answer 3

What's wrong with gmake?

What issues does it have that mean you want to use it. There's no point in recommending another tool if it has the same perceived issues as gmake.

we're using gmake in our build system and we're extremely happy with it's performance, flexibility and features

Answer 4

How about "gnu make"?

You asked for something like it without giving any indication of what features you want that aren't supported by gnu make.

Answer 5

SCons and waf are good (well, IMHO anyway) build systems, and depend only on Python.

Answer 6

CMake should answer most, if not all for your requirements.

• It will generate the Makefiles for you.

• It has a good domain specific primitives, plus a simple language for the times you need to do something special.

• It solves most of the problems with recursive make (see recursive make is considered harmful paper).

• It uses an out-of-source build, so you have your bin / src separation.

I found it easy to write, easy to maintain, and fast to build.

... Plus:

• It is cross platform.

• With CText and CDash it has what you need for setup a continues integration service.

See also this answer to Recursive Make - friend or foe?

Answer 7

I use cmake, and I'm very glad I made the switch.

EDIT

Feature list as found in the wikipedia article:

• Configuration files are CMake scripts, which use a programming language specialized to software builds
• Automatic dependency analysis built-in for C, C++, Fortran and Java
• Support of SWIG, Qt, via the CMake scripting language
• Built-in support for many versions of Microsoft Visual Studio including versions 6, 7, 7.1, 8.0, and 9.0
• Generates build files for Eclipse CDT (C/C++ Development Tools)
• Detection of file content changes using traditional timestamps,
• Support for parallel builds
• Cross-compilation
• Global view of all dependencies, using CMake to output a graphviz diagram
• Support for cross-platform builds, and known to work on
  • Linux and other POSIX systems (including AIX, *BSD systems, HP-UX, IRIX/SGI, and Solaris)
  • Mac OS X
  • Windows 95/98/NT/2000/XP, Windows Vista and MinGW/MSYS
• Integrated with DART (software), CDash, CTest and CPack, a collection of tools for software testing and release

But to be honest: Just about anything is better than the gnu toolchain.

Answer 8

apache Ant

Answer 9

G'day,

I'd agree with the couple of answers, so far, that recommend sticking with gmake.

Maybe have another look after reading the first few chapters of Robert Mecklenburg's excellent book "Managing Projects with GNU Make" (sanitised Amazon link).

Or, even better, is to search out a copy of the previous edition called "Managing Projects With make" by Andrew Oram and Steve Talbott. The first few chapters give an excellent description of (g)make and [Mm]akefile basics.

And I see you can buy a second hand copy of the 2nd ed. from Amazon for the princely sum of $0.01! (sanitised Amazon link)

After reading that intro you'll even understand how make is backward chaining, which is a bit non-intuitive when just looking at make's behaviour.

HTH

cheers,

Answer 10

Boost.Jam

It has the features you named

• command line interface;
• easy;
• it comes from the C++ library collection Boost, so it has good support for C++ (and it's not limited to C++, either);
• it stores executables in places under the bin directory, depending on what build request you've commanded. If you use gcc 4.3.2, than you get the executables under
  • bin/gcc-4.3.2/debug -- when executing bjam
  • bin/gcc-4.3.2/release -- when executing bjam release
  • bin/gcc-4.3.2/release/inlining-off/threading-multi -- when executing bjam release inlining=off threading=multi
  • bin/gcc-4.3.2/release/threading-multi -- for bjam release inlining=full threading=multi because inlining=full is default for release.
• it doesn't need the full Boost library collection, only Boost.Build and Boost.Jam are necessary;
• platform independent;
• the Jamfile syntax is easy, but powerful;
• you can divide the build config into many Jamfiles in subdirectories.

Answer 11

Autotools -- autoconf/automake/libtool they are very poweful build instruments.

Its take some time to start with them, but after -- they serv you very well.

And what is more important they are significantly more powerfull then their replacements (CMake, BJam, SCons etc).

How are they more powerfull?

• Transparrent support of building both static and shared libraries via libtool.
• Support of uninstall (no in CMake)
• Support of standard installation paths -- very important in packaging.
• Full support and integration of gettext.
• Transparent and strightforward support of cross compilation.

Many things. CMake may do most of things but for each one of them you should write long scripts or specify many things manually.