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.

On Monday, 1 July 2013 at 16:32:55 UTC, Kagamin wrote:
> 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 think this should be properly solved by making compiler a daemon/server, not by a build tool.

On Monday, 1 July 2013 at 03:26:22 UTC, Graham St Jack wrote:
> On Thu, 27 Jun 2013 22:49:41 +0000, Graham St Jack wrote:
> Fixed the problem, and also:
>
> * split bub.d up into several smaller files,
>
> * added a Makefile to bootstrap the building of bub, and
>
> * added a bub.cfg and Bubfile as a trivial example of how to use bub.

Please add an "install:" target to the Makefile.

Thank you.

On Tue, 02 Jul 2013 14:07:16 +0200, eles wrote:

> On Monday, 1 July 2013 at 03:26:22 UTC, Graham St Jack wrote:
>> On Thu, 27 Jun 2013 22:49:41 +0000, Graham St Jack wrote: Fixed the problem, and also:
>>
>> * split bub.d up into several smaller files,
>>
>> * added a Makefile to bootstrap the building of bub, and
>>
>> * added a bub.cfg and Bubfile as a trivial example of how to use bub.
> 
> Please add an "install:" target to the Makefile.
> 
> Thank you.

A better makefile is in progress, and it will have an install target.