On Thu, Mar 19, 2015 at 15:31:49 +0000, Bruno Medeiros via 
Digitalmars-d-announce wrote:
> 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
what changed.

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
single invokation).


Reply via email to