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
. 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
. Separate compilation. One file changes, only one file gets
. 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!