DDT 0.11.0 released

[Manu via Digitalmars-d-announce]

On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
> On 19/03/2015 14:45, Trent Forkert wrote:
>>
>> On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote:
>>>
>>> Semantics analysis you can get by simply opening .d file in CDT
>>> project is very limited compared to opening dub project because it
>>> can't know the import paths for dependencies or pretty much anything
>>> about project structure apart from opened file. This isn't much.
>>
>>
>
> Exactly.
>
>> It seems you are right that it *is* limited, but it shouldn't be. CMake
>> emits include/import paths into the project structure. I had thought it
>> emitted into .project, but evidently emits into .cproject. If DDT
>> supported a .dproject I could also emit, I could get it to work.
>
>
> DDT does support a .dproject ... it's called dub.json ! ;)
>
> I'm dead serious here though. Why would I invent my own file format to
> describe source folders and include/imports paths when dub.json does that
> already?? It would be silly to use anything else. If you absolutely don't
> want to use DUB to build things, there are ways to disable the DUB builder,
> as mentioned before in this thread, and this way you'll use dub.json merely
> to describe the import path structure of the D project.

I would imagine that if you had complete control over the project
description and build process, it would be much easier to integrate
with other components in Eclipse?
Of course, I have no idea whether that's true or not. But I will
hazard a guess that using dub in this way must make it harder for you
to interact with CDT/java tools than otherwise?

It would also be really nice to have a UI with tick boxes and select
boxes for all the relevant build settings like CDT.