Announcing bottom-up-build - a build system for C/C++/D
Graham St Jack
graham.stjack at internode.on.net
Wed Jun 26 17:10:37 PDT 2013
Bottom-up-build (bub) is a build system written in D which supports
building of large C/C++/D projects. It works fine on Linux, with a
Windows port nearly completed. It should work on OS-X, but I haven't
tested it there.
Bub is hosted on https://github.com/GrahamStJack/bottom-up-build.
Some of bub's features that are useful on large projects are:
Built files are located outside the source directory, using a different
build directory for (say) debug, release, profile, etc.
Very simple configuration files, making the build infrastructure easy to
maintain.
Automatic deduction of which libraries to link with.
Automatic execution and evaluation of tests.
Enforcement of dependency control, with prevention of circularities
between modules and directories.
Generated files are not scanned for imports/includes until after they are
up to date. This is a real enabler for code generation.
Files in the build directory that should not be there are automatically
deleted. It is surprising how often a left-over build artifact can make
you think that something works, only to discover your mistake after a
commit. This feature eliminates that problem.
The dependency graph is accurate, maximising opportunity for multiple
build jobs and thus speeding up builds significantly.
An early precursor to bub was developed to use on a large C++ project
that had complex dependencies and used a lot of code generation. Bub is a
major rewrite designed to be more general-purpose.
The positive effect of the bub precursor on the project was very
significant. Examples of positive consequences are:
Well-defined dependencies and elimination of circularities changed the
design so that implementation and testing proceeded from the bottom up.
Paying attention to dependencies eliminated many unnecessary ones,
resulting in a substantial increase in the reusability of code. This was
instrumental in changing the way subsequent projects were designed, so
that they took advantage of the large (and growing) body of reusable code.
The reusable code improved in design and quality with each project that
used it.
Tests were compiled, linked and executed very early in the build -
typically immediately after the code under test. This meant that
regressions were usually detected within a few seconds of initiating a
build. This was transformative to work rate, and willingness to make
sweeping changes.
Doing a clean is hardly ever necessary. This is important because it
dramatically reduces the total amount of time that builds take, which
matters on a large project (especially C++).
Having a build system that works with both C++ and D meant that it was
easy to "slip" some D code into the project. Initially as scripts, then
as utilities, and so on. Having side-by-side comparisons of D against
bash scripts and C++ modules had the effect of turning almost all the
other team members into D advocates.
More information about the Digitalmars-d-announce
mailing list