DDT 0.11.0 released

[Bruno Medeiros via Digitalmars-d-announce]

On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote:
> I just checked out DDT, and I noticed it seems to use DUB... >_<
>
> Why this marriage? I was really hoping it would be a lot more like CDT
> (ie, raw and flexible).
> In the project configuration I just see the one "DUB Options" box. The
> comprehensive suite of build options CDT presents would be much nicer.
>

It makes no sense for DDT to use anything else than DUB.

At a minimum, DDT needs a way to describe projects: the source files 
that are part of the project, and which other projects are dependencies 
of said project.
Other aspects of a projects that are good to be able to describe are: 
which build configurations the project supports, which executables are 
produced (if any), etc..

Now the reason DUB is used is that it's a bad paradigm for this 
description mechanism to be Eclipse/DDT specific. It's unequivocally 
much better to be Eclipse-independent, such that other tools (not just 
other IDEs, but even other command-line analysis tools) can understand D 
projects/bundles/packages just as well as DDT. It also saved me a lot of 
work. If I had to develop my own format to describe all these aspects, 
it would not be as good as DUB's, guaranteed! I reckon this is true for 
any other D IDE out there.


> DUB is insufficient for any of my projects, and sadly, that makes DDT
> insufficient for my projects too:(
> The problem with DUB is it's self-contained. My projects involve
> cross-language interaction, and the build environments can be complex.
> DUB can't express this.

Why is it insufficient? You don't have to use DUB to the exclusion of 
everything else. Isn't the use of the preGenerateCommands 
(http://code.dlang.org/package-format#build-settings) enough to call 
these other build systems you use?

The only problem so far is that DDT doesn't support mutiple build 
configurations, but that's a DDT limitation, not a DUB one.

You can also disable the DUB builder in DDT, as albatroz mentioned, 
however that isn't ideal since you won't get the compiler build errors 
reported back to Eclipse (DDT only has parsing errors built-in, other 
errors come externally, from the compiler.).

There should be a way to integrate DUB with your build environment.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros