DDT 0.11.0 released

[Trent Forkert via Digitalmars-d-announce]

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.

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

> I don't really understand the part about putting paths to 
> .project though

That was a misunderstanding of Eclipse internals on my part. When 
the basic case of completing symbols from phobos worked, I just 
assumed that those include directories were being written to a 
portable place, since I hadn't done anything special for Eclipse 
project generation.

> how it can possibly put something that is language specific 
> there?

Include directories are not language specific, at least not in 
CMake.