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.
