☰ Menu+  instagram  ringing ear 

geekstuff | gameswf | Textweb | Chunked LOD | dumbuild

Cheat sheets: CVS | cygwin | Debian | Emacs | MythTV

NOTE: dumbuild is so far just a personal experiment. Proceed at your own risk.


dumbuild is a build tool for building C++ programs, written in C++. The goals include:

Getting dumbuild

The code is here: http://tu-testbed.svn.sourceforge.net/viewvc/tu-testbed/trunk/tu-testbed/dumbuild/

You can grab it out of SVN or just poke around in there if you're curious.

When it's more mature I'll provide .zip and .tar.gz archives.

A prebuilt statically-linked windows executable is here: http://tulrich.com/geekstuff/dumbuild/dmb.exe

Building dumbuild

dumbuild bootstraps itself from its wrapper script, the first time you run it. On Windows:

> dmb.bat

On Linux etc:

# ./dmb

If all goes well, you should get dmb.exe (Windows) or dmb (Linux etc) in the subdirectory dmb-out/bootstrap .


On Windows:

> dmb.bat [options] [target-name]

On Linux etc:

# ./dmb [options] [target-name]

The target is found by looking for a build.dmb file in the specified
target's path, and then looking for the named target within that
build.dmb.  For example:

  dmb libs/base/math

will try to parse the file "libs/base/build.dmb" for a target
named "math", and build it according to the target's
specification.  If not specified, the default target is "default".

options include:

  -C <dir>     Change to the specified directory before starting work.
               This should have the effect of invoking dmb from that

  -c <config>  Specify the name of a build configuration (i.e. compiler 
               & mode).  Supplied configurations in the default root.dmb
               If not specified, the default configuration is 
               "default", which tries to do some auto-detection for
               an appropriate build configuration.

  -r           Rebuild all, whether or not source files have changed.

  -v           Verbose.  Does a lot of extra logging.

  --test       Run internal unit tests.

The project root directory is located by searching upward from the
current directory for a file named "root.dmb".  root.dmb may
contain project-wide defaults.  Target paths may be specified in
relation to the project root.

The build output goes in <project-root>/dmb-out/<config-name>

Without any options, "dmb" builds the target "default" using the default configuration "default".


> dmb -c vc8-release

Scans build.dmb for the default target, and builds it using the vc8-release configuration.


root.dmb -- put this in the root directory of your project. All the pathnames in dumbuild config are relative to this root. This is also where you probably want to put the compiler configuration (command-line templates and such). Example

build.dmb -- these files specify your actual "targets" (i.e. libs and executables). Put these throughout your project tree, wherever you need them. The recommended pattern is to put one in each source directory. You can have more than one target in a single directory; this is normal if you want some additional structure inside the directory. A target can actually pull sources from outside the directory its build.dmb file is in, though this is more intended for special circumstances, like building sources from a foreign code tree. Example

Build Language

The build language syntax is JSON ("Javascript Object Notation").

TODO explain semantics


There are many build tools in the world -- why another one? Partly for fun, but mostly to scratch an itch: there is no ideal single build tool for a small or medium-sized open source project that wants to support both Windows and non-Windows platforms. Here's a rundown of my take on the top contenders:

JamPlus is closest to the ideal. The minor knocks on it are that it's not trivial to bootstrap, and in my opinion the config language is hard to use. People use it for big commercial projects and it has a reputation for excellent speed.

Scons is full of features and has a reasonable config language (based on Python). But, it's written in Python, it's not tiny, and unfortunately it can be egregiously slow on big projects. I don't think it's a great choice for embedding in a small or medium-sized open-source project, mainly because it would be bigger than the typical host project, and it has a dependency on Python.

GNU make is what I have used for a long time for my own open-source stuff. It's fast, fairly ubiquitous, and I'm used to it. I don't mind it too much, but it's not the most elegant thing, the header dependency checking is terrible, and it seems to perplex most Windows programmers.

Project file generators like cmake and gyp have increased in popularity, and have some adherents. Personally I have a deep-seated dislike for anything that relies on Visual Studio as a build tool. Same with Xcode on Mac. I prefer to use the same non-GUI build tool across multiple platforms.


tu@tulrich.com |