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). --Ben
