On Thu, Mar 19, 2015 at 15:31:49 +0000, Bruno Medeiros via
> Indeed, I reckon in these more complex examples, you'd call DUB from
> make/cmake/whatever. DUB would be in charge of building the D library
> aspect/component of that whole project. I don't see why this would not
> be possible, or otherwise why it would be a tangled messed.
If dub needs things built earlier and then the D code is used by CMake,
dependency tracking becomes very manual; it's better to have one tool
know the entire build structure here.
> It might force to think of your build components in a more
> structured/componentized way, instead of the paradigm of building on a
> file by file basis, the `make` way. (I've only used make though, not
> cmake, so dunno how much this comment applies to the later)
Building file-at-a-time is, for developers, on the whole faster than
"unity" builds because you can parallelize it and only have to build
CMake only really works with .d -> .o rules (Java support bends this
AFAIK due to restrictions in javac, but I vastly prefer -j8 over a