10

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.

Willi Mentzel
  • 27,862
  • 20
  • 113
  • 121
tuergeist
  • 9,171
  • 3
  • 37
  • 58
  • Sorry that I must refine my question. But I made too many implications that I'd have told you – tuergeist Sep 08 '09 at 15:01
  • Might want to make this community wiki. I don't think asking or answering this really reflects much objective knowledge, just which build systems a person has experience with. – jalf Sep 08 '09 at 15:07
  • Recursive make is not to be used, as you have discovered. The top level makefile is supposed to include the others not call them. – Joshua Sep 08 '09 at 15:07
  • Why is adding dependencies on Python or Java a concern? I can understand wanting to avoid dependencies on obscure or expensive products, but programming language virtual machines, especially ones as commonly-used as Python and Java, are sort of standard. – Imagist Sep 08 '09 at 15:11
  • @Imagist: Python, e.g., changed the syntax towards version 3.1 - if I update Pythons for any reason, the build system may be broken afterwards. For Java, I'll accept the dependency as it is more stable. – tuergeist Sep 08 '09 at 15:14
  • Why change? [Learn to use it](https://github.com/deminets/unimake). – dsnk Sep 15 '17 at 10:30

9 Answers9

19

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.

soulmerge
  • 73,842
  • 19
  • 118
  • 155
  • Another advantage is easy cross platform installation/packaging commands. – thekidder Sep 08 '09 at 15:06
  • I actually like gmake, with a bunch of special makefiles I've prepared over the years. But I recently switched to cmake and it simplified cross-platform development (Linux, OS X, Windows) so much that cmake is my new default for new projects. – Larry Gritz Sep 08 '09 at 16:07
  • I see cmake more like complete replacement for automake/conf including gmake. And I agree that cmake is far easier to use than somewhat arcane m4 macros ;-) Additionally, for large projects, it is significantly faster than gmake. – Gunther Piez Sep 08 '09 at 16:20
  • 2
    CMake is the only tool out there capable of generating **real** Visual Studio projects, i.e. not makefile-projects which invoke some external tool. – JesperE Sep 13 '09 at 19:17
  • 1
    "Another advantage is easy cross platform installation/packaging commands" I think that `./configure --host=arm-linux-gnueabi` or `./configure --host=i586-mingw32msvc` is simple enouhg? – Artyom Oct 24 '09 at 07:48
9

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

Cat Plus Plus
  • 125,936
  • 27
  • 200
  • 224
  • Hmm, ok. But as you stated waf brings dependencies to Python :( – tuergeist Sep 08 '09 at 14:52
  • 1
    +1 for SCons. The Python dependency isn't an issue--we build on Mac, Win, Linux. – i_am_jorf Sep 08 '09 at 16:04
  • I like waf better than scons, but I can't quite understand how to extend either for the life of me. Ultimately I prefer make for how easy it is to add new rules/target types and for how fast it starts working. Scons performance on large projects is just woeful. – Bklyn Jan 14 '10 at 19:39
8

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.

Bryan Oakley
  • 370,779
  • 53
  • 539
  • 685
8

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.
Chris Huang-Leaver
  • 6,059
  • 6
  • 41
  • 67
Adrian Panasiuk
  • 7,249
  • 5
  • 33
  • 54
7

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?

Community
  • 1
  • 1
Chen Levy
  • 15,438
  • 17
  • 74
  • 92
5

SCons + swtoolkit

Grant Limberg
  • 20,913
  • 11
  • 63
  • 84
3

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,

Rob Wells
  • 36,220
  • 13
  • 81
  • 146
  • I think this answer isn't helpful as its not an answer to my question. I did not asked for a guide recommendation. – tuergeist Sep 08 '09 at 15:03
  • 1
    @tuergeist, i considered that before answering. but i did find i considered make in a new light when i began to understand its inner workings more deeply. hence the pointers to two excellent sources of info. (-: – Rob Wells Sep 08 '09 at 15:18
3

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.

Artyom
  • 31,019
  • 21
  • 127
  • 215
  • It also have many drawbacks. For one it puts files everywhere and has not builtin mechanism I know of to remove those. It's a bit of concern when you use some versioning tool. Could you also elaborate in what ways autotools are more powerfull than says bjam or CMake ? – kriss Oct 24 '09 at 02:53
  • "For one it puts files everywhere and has not builtin mechanism I know of to remove those." First of all you may do out-of-source builds. So all files will be stored in other directory. – Artyom Oct 24 '09 at 07:45
  • Please add some pointer on how to do that. It's trivial using bjam or cmake, but I never saw one project using autotools that does not clutter source tree with a bunch of generated files. And I'm not speaking only of files generated by the building process itself but also of the bunch of files generated as soon as you type configure. I would be quite surprised if it is possible at all. If there is not generated Makefile for instance how could make possibly work after the configure part in the common triptic "./configure ; make ; make install". – kriss Oct 26 '09 at 23:01
  • 1
    >how could make possibly work after the configure part in the common triptic "./configure ; make ; make install". < Very simple: "mkdir build; cd build; ../package-xyz/configure; make; make install" -- You can run configure out of the source tree. More then that, some packages like gcc ask you to do out of source build. And do not support "in source" builds. – Artyom Oct 27 '09 at 08:56
  • 1
    Also cleaning up is quite simple : make distclean does the job. – Artyom Oct 27 '09 at 08:57
2

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

Glen
  • 21,816
  • 3
  • 61
  • 76
  • 1
    Nothing's wrong with it. 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. ;) – tuergeist Sep 08 '09 at 14:55
  • @tuergeist, some fair points. We're using gmake with non-recursive makefiles and it's so much better than the traditional recursive makefile system. The only real downside is that it takes a lot of work to setup the initial non-recursive system. on the plus side non-recursive make has dramatically reduced our build times (3000 source files, ~1 million lines of code compiled in about 6-8 minutes), allows great dependency tracking and parallel builds. (all things you can probably get from other tools) – Glen Sep 08 '09 at 15:01
  • 1
    @Glen: sounds good. My last experience was to wait 45mins for the nearly the same amount of code and files on a dual-core 3GHz PC :( (with recursive make files and a three stage build system - stages for idl, libs+objects, binaries)) – tuergeist Sep 08 '09 at 15:07