Announcing bottom-up-build - a build system for C/C++/D

[Graham St Jack]

On Mon, 01 Jul 2013 18:32:54 +0200, Kagamin wrote:

> Hooo, a self-contained build tool? That's cool.

I like to think so.

> 1. Are arbitrary make-style commands supported? For example, on windows
> one may want to compile resources. Resources consist of a declaration
> .rc file, icons and manifest files, which are compiled into .res file,
> though only .rc file is passed to the resource compiler, but other files
> are still dependencies of course.

Not completely arbitrary. Yous define (currently one-line) commands in 
bub.cfg, with access to variables that are expanded at the last moment 
before the command is issued. Some of the variables are pre-defined and 
populated by bub, and others you define yourself.

> 2. How to do heterogeneous linking? Again on windows an executable can
> be linked from code .obj's, resource .res and module definition .def:
> gcc main.o r.res mytool.def -o mytool.exe

There isn't any fundamental reason why things like resource files can't 
be linked in, but I would probably have to make a few improvements. The 
use case that bub was forged in was linux-hosted C/C++ with lots of code 
generated from IDL files and the like.

> 3. Probably not actual for big
> projects. Can build workspase be created automatically by bub instead of
> explicitly by bub-config... for some default mode?

You set up a build directory with bub-config. I can't currently see any 
reason why it would be useful for bub to invoke bub-config itself.

Re big projects - I guess it depends on what you mean by big. See the 
post from Clive Hobson, which describes a project that bub works well on. 
That project seems pretty big to me.


> 4. If a build server does builds from scratch, shouldn't it be better
> for performance to compile several source files in one command? Also
> applies to user builds: when one wants to install a project from source,
> he usually does it only once and from scratch. Have you any idea, how
> this affects compilation speed of c, c++ and d? Though dmd frontend can
> go out of memory.

I assume you mean my preference for explicitly building object files. I 
like this because:
* It opens up more opportunities for using multiple cores (-j9)
* Dependency/reference tracking is simplified.
* Test utilities are easier if the code under test is available in a lib.