DDT 0.11.0 released

[Dicebot via Digitalmars-d-announce]

On Friday, 20 March 2015 at 15:47:09 UTC, Trent Forkert wrote:
> On Friday, 20 March 2015 at 14:36:51 UTC, Dicebot wrote:
>> I wasn't referring to the vim vs IDE holy debate. I often use 
>> IDE myself but never use interal build systems tied to IDE - 
>> mostly for portability reasons. It is good to know that your 
>> project will always be built the same way - on local 
>> development box, in packaging script, on headless CI box.
>
> Which is one of the reasons I use CMake ^_^. It ensures the 
> build button in your IDE behaves the same as make, regardless 
> of which box the code is built on.

It is _supposed_ to be the same, but not necessarily is. Bugs in 
CMake generators are not impossible.

>>>> 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.
>>>
>>> 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.
>>
>> .dproject is exactly dub.json
>
> As I said in my response to Bruno earlier, this still requires 
> dub for things to work, which isn't an acceptable solution. A 
> real .dproject would not require tools outside of Eclipse/DDT 
> to function, and would preferably be similar to .project and 
> .cproject.

And I don't understand why it is not acceptable. dub is de-factor 
part of standard compiler toolchain for D. It is developed as 
D-Programming-Language organization project and planned for 
eventual distribution with compiler. Saying that is unacceptable 
as dependency is similar to saying that Phobos is unacceptable as 
dependency.

>> how it can possibly put something that is language specific 
>> there?
>
> Include directories are not language specific, at least not in 
> CMake.

Sounds like design mistake to me. There is nothing similar 
between include directories in C and import paths in D. Even 
within D -J paths and -I paths need to be treated differently.