DDT 0.11.0 released

[Manu via Digitalmars-d-announce]

On 20 March 2015 at 01:31, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> 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.