DDT 0.11.0 released

Mon Mar 23 07:10:59 PDT 2015

On 20/03/2015 05:04, Manu via Digitalmars-d-announce wrote:
> 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.
>

We might have different notions of what "as good as DUB's" means then.
Let's look at these two use cases:

* Do those IDEs allow a project specifying a dependency on an D library, 
without having to download the library, or to configure the build 
settings for the library? And does doing so still make it possible to 
integrate with C/C++ projects?

* Can you have a cross-plaftorm workspace/solution, and when building 
the D part of it, the IDE parses the error messages of the D compiler 
and reports then to the UI in the editor?

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

Yes, it would be nice if DDT would automatically integrate with CDT, and 
handle this use case seamlessly (regardless of using DUB internally or not).

But this would be complex work, for little gain. Let me go into detail.

First of all, "CDT works, and I don't know how": yeah, but CDT only had 
to concern himself with C/C++, no cross-language stuff. Like you said, 
DDT and DUB also works well if you stick to the D ecosystem only. If you 
put a cross-language requirement on DDT, you're actually asking more of 
DDT than CDT had to worry (which means more work, more complexity).

CDT and VisualStudio are IDEs with big companies backing them, they both 
had multiple developers working on them, full-time, for many, many years 
now.

DDT only has had me working on it, on a volunteer basis (although some 
of the work I do there, and in Goclipse and RustDT, is related to some 
commercial work I do). Still, it's just me ATM, so there is an order of 
magnitude of difference of manpower available. You can't expect the same 
level of completeness. Only the most critical/important features can be 
worked on (or simple to implement ones).

Also, there is limited gain. Sure, C/C++ and D are related, but
A) Not everyone in D world is that concerned with that scenario, C/C++ 
integration.
B) More importantly, adding DDT integration with CDT, would only benefit 
users of DDT&CDT combined, which is a fraction of 'C++ & D' users. What 
about users (and you might be one) that at the end of day don't use 
DDT/CDT because you can't debug properly on Windows, and go to VisualD?
What about CDT users that use unmanaged builds? (unmanaged builds is a 
CDT project option that has the user manually write/manage the build 
system files for that CDT project). Unmanaged builds are likely to be 
structured/specified in a way that would prevent seamless DDT 
integration. Rather, a DDT project using a CDT unmanaged build project, 
would have to be unmanaged as well, to a degree at least (that is, the 
user would have to fiddle with build systems configuration files). That 
further narrows down the population who would benefit from DDT+CDT 
integration.

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