DDT 0.11.0 released

[Manu via Digitalmars-d-announce]

On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
> 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.

I use Mono-D and VisualD extensively, and in lieu of those, I fallback
to makefiles.
Those certainly did make their own equivalent build systems matching
the IDE's existing styles.
Those IDE's integrate D nicely with the C/C++ experiences.


>> 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?

I have no idea how Eclipse operates internally... and I shouldn't have
to. Isn't that the point of an IDE?
All I can say is that CDT works, and I don't know how. If DDT doesn't
automatically work with it out of the box, then the IDE experience is
kinda pointless (to me at least).
If I have to fiddle with a build system by hand, then that undermines
the whole point of the IDE as far as I'm concerned.

C/C++ and D are related, and they must interoperate. It's the top of
the D roadmap.
If I'm an IDE user, I think that's more-or-less an admission that I
don't understand build environments, and I don't want to.
So from that perspective, I think it would be valuable work to make
sure DDT and CDT understand eachother.


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

There may very well be, but it would seem to be more work than not,
and added complexity and for the cost of additional work doesn't make
for a good sales pitch :)
As far as I can tell, dub is good for self-contained D apps, and
that's about it. Beyond that, there are much simpler solutions, and
that includes IDE support.