I wanted to work on this a little more before announcing it, but it seems I'm going to be busy working on trying to get unit-threaded into std.experimental so here it is:


If you're wondering about the name, it's because it's supposed to build on dub.

You might wonder at some of the design decisions. Some of them are solutions to weird problems caused by writing build descriptions in a compiled language, others I'm not too sure of. Should compiler flags be an array of strings or a string? I got tired of typing square brackets so it's a string for now.

Please let me know if the API is suitable or not, preferably by trying to actually use it to build your software.

Existing dub projects might work by just doing this from a build directory of your choice: "reggae -b make /path/to/project". That should generate a Makefile (or equivalent Ninja ones if `-b ninja` is used) to do what `dub build` usually does. It _should_ work for all dub projects, but it doesn't right now. For at least a few projects it's due to bugs in `dub describe`. For others it might be bugs in reggae, I don't know yet. Any dub.json files that use dub configurations extensively is likely to not work.


. Make and Ninja backends (tup will be the next one)
. Automatically imports dub projects and writes the reggae build configuration . Access to all objects to be built with dub (including dependencies) when writing custom builds (reggae does this itself)
. Out-of-tree builds, like CMake
. Arbitrary build rules but pre-built ease-of-use higher level targets . Separate compilation. One file changes, only one file gets rebuilt
. Automatic dependency detection for D, C, and C++ source files
. Can build itself (but includes too many object files, another `dub describe` bug)

There are several runnable examples in the features directory, in the form of Cucumber tests. They include linking D code to C++.

I submitted a proposal to talk about this at DConf but I'll be talking about testing instead. Maybe next year? Anyway, destroy!


Reply via email to