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.

This build system seems to be very well suited for building complex large projects in a sensible way.

I successfully tested the example build on Debian linux. I will definitely explore this further using one of my own projects.

One issue I immediately ran into, is when I run bub incorrectly it hangs after writing the "bail" message to console. ctrl-c does not kill it, and I have to run a process kill commandto terminate.

Seems it gets stuck in doBailer() while(true) loop, but I only glanced at the source quickly before posting back here.

--rt

On Thursday, 27 June 2013 at 05:44:16 UTC, Rob T wrote:
> One issue I immediately ran into, is when I run bub incorrectly it hangs after writing the "bail" message to console. ctrl-c does not kill it, and I have to run a process kill commandto terminate.

CTRL-Z works for me. I think it expects input.

On Thursday, 27 June 2013 at 07:32:32 UTC, eles wrote:
> CTRL-Z works for me. I think it expects input.

Ignore it. It just suspends it.

Hm, bub.. Sounds like it should work with 'dub' nicely ;)

Looks promising and I'd really love to see some build tool other then rdmd getting to the point it can be called standard. Makefile's sometimes are just too inconvenient.

On 6/26/13 5:10 PM, Graham St Jack wrote:
> Bottom-up-build (bub) is a build system written in D which supports
> building of large C/C++/D projects.

http://www.reddit.com/r/programming/comments/1h6p2w/bottomupbuild_a_build_system_for_ccd/


Andrei

On Thu, 27 Jun 2013 07:44:07 +0200, Rob T wrote:

> This build system seems to be very well suited for building complex large projects in a sensible way.
> 
> I successfully tested the example build on Debian linux. I will definitely explore this further using one of my own projects.
> 
> One issue I immediately ran into, is when I run bub incorrectly it hangs after writing the "bail" message to console. ctrl-c does not kill it, and I have to run a process kill commandto terminate.
> 
> Seems it gets stuck in doBailer() while(true) loop, but I only glanced
> at the source quickly before posting back here.
> 
> --rt

I recently made a big change to the inter-thread communication code, and there are a few problems there still. I will look into it.

On Thu, 27 Jun 2013 12:24:27 +0200, Dicebot wrote:

> Hm, bub.. Sounds like it should work with 'dub' nicely ;)

Maybe so...

> 
> Looks promising and I'd really love to see some build tool other then rdmd getting to the point it can be called standard. Makefile's sometimes are just too inconvenient.


This isn't a build tool for everyone, but it really does make a big difference on big projects.

Am Thu, 27 Jun 2013 10:26:01 +0200
schrieb "eles" <eles@eles.com>:

> On Thursday, 27 June 2013 at 07:32:32 UTC, eles wrote:
> > CTRL-Z works for me. I think it expects input.
> 
> Ignore it. It just suspends it.

You might want to check how many programs you thought to have "killed" like this so far in your running session. It might eat up your RAM.

-- 
Marco

On Thursday, 27 June 2013 at 23:03:40 UTC, Graham St Jack wrote:
>
> This isn't a build tool for everyone, but it really does make a big
> difference on big projects.

Well I'm noticing some interesting concepts, such as being able to associate an include or import file with the library to link in, so that it gets done automatically simply by using the include/import file, great idea assuming I understood that correctly.

One thing you may want to consider, or maybe this is already possible, is add the ability to optionally specify something like *.d so that all .d files get included from a folder, rather than have to always individually specify them manually.

Also more concise documentation with clearer examples would be invaluable. I'm currently unsure if I need to restructure my existing project folders to fit bub or if bub can be configured to fit my existing projects.

--rt