On 20 March 2015 at 01:31, Bruno Medeiros via Digitalmars-d-announce <[email protected]> wrote: > On 19/03/2015 11:18, Dicebot wrote: >> >> On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: >>> >>> Arbitrary, contrived example (though not entirely unrealistic): >>> * a C(++) executable needs a static D library >>> * Said D library in turn uses a C(++) library >>> * All three of these are built as components of the same project >>> >>> So now I need a weird tangled mess of build systems calling each other >>> back and forth. Dub really doesn't pull its weight here. >> >> >> I call dub from makefile rules and feel pretty comfortable about such >> pattern (apart from being not-so-portable compared to raw dub). And >> building anything via IDE is just asking for trouble :) >> > > 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.
Pushing variables, lib paths, include paths, etc around immediately comes to mind. > 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) In premake, D projects are emit as a single invocation of the compiler given all source files at once, and this works seamlessly with C/C++ projects which are done in the traditional file-by-file way. VisualD and Mono-D also perform D compilation in single step, while interoperating with C compilation in the traditional way.
