On 23/03/2015 23:01, Ben Boeckel via Digitalmars-d-announce wrote:
> On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via Digitalmars-d-announce wrote:
>> On 2015-03-23 13:54, Bruno Medeiros wrote:
>>> There's no plans ATM to integrate with CDT itself. (I don't even know
>>> what integration with java tools would mean here) Even for CDT, I don't
>>> see what much would there be to integrate, other than the build system.
>>
>> I would guess he means using C(++) files and D files in the same project
>> and the build system would just work.
>
>>From what I understand[1] of Eclipse (which I admit isn't much from a
> user's PoV), it supports "natures" to be loaded which provide
> functionality. Now I have no idea how much work this is, but it would be
> nice to have a nature for D support (syntax highlighting, completion,
> etc.). If it includes dub, great, but it might be worth it to have a
> separate nature for that. CMake (and other theoretical tools) would then
> just add the D support nature to handle the D files and use the existing
> build support. Projects created through DDT itself could add the dub
> nature by default (FWIW, I don't think CDT generates CMake-based
> projects out of the box either).
>
> Basically, make DDT suitable for using it with other projects which
> don't use dub because it doesn't suit the upstream project whether it be
> because the project is more than some D code, YAML is preferred to JSON
> or whatever.
>
> Take my gunroar[2] repo for example. It's mainly D code, but there is
> some C and Java in the src/android directory. If one were working in
> Eclipse with it, it would be nice to support using CDT features for the
> C code, the native Java support for the Java code, DDT for the D code,
> and the build button to put it all together.
>
> --Ben
>
> [1]This is based on my experience where enabling the Android bits in an
> Eclipse project generated by CMake is to allow users to add natures to
> the generated .project file using the ECLIPSE_EXTRA_NATURES global
> property.
> [2]https://github.com/mathstuf/abagames-gunroar
>

Yes, there is a D nature for Eclipse's .project:
org.dsource.ddt.ide.core.nature
Curiously though, a few DDT features will work fine without that nature, namely semantic features (code completion, go to definition, etc.). They even work with external files (files not in an Eclipse project), as long as they are part of a DUB bundle (known in DUB as a "package").

This is because, for example, when invoking code completion on a D source, DDT will try to find a "dub.json" file in the tree of parent dirs of the D file. Once it finds it, it will analyze the source structure of that bundle and all its dependency bundles (using `dub describe`, and then code completion will have all module information correctly available. And the caching of the semantic engine will still work just fine. :)


As for not using DUB. Hum, I could add feature of a flag to a project options to prevent it from using DUB (the executable). This way the DUB build would be a no-op, and `dub describe` would not be run either. You would still have to use the dub.json file to describe source folders though. (Again there's no sense in making a new format to describe this)

As for your gunroar example. I don't know how CMake generates an Eclipse project, but that scenario that sounds like it should have multiple Eclipse projects generated. (One for D code, one for C bits, another for Java bits) Trying to shove everything in one project wont work properly. (The directory structure of gunroar might have to be changed a bit to accommodate that though)

An Eclipse project is a build "unit", and is not the equivalent of a VisualStudio solution. An Eclipse workspace is much more akin to a VS solution.

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

On 06/03/2015 17:37, Bruno Medeiros wrote:
> A new version of DDT is out. Improvements to the semantic engine,
> important fixes:
> https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0
>
>
> There has also been some big internal changes lately, so these latest
> releases might be a bit more buggy than usual. (as exemplified by the
> regression where code folding and quick-outline were broken :s - and
> shame on me for taking so long to notice that)
>

Note that there is a tool recently released, Eclipse Optimizer, that can help optimize Eclipse startup time:

"Also, to improve Eclipse performance and startup time, it is recommended you tweak the JVM parameters. There is a tool called Eclipse Optimizer that can do that automatically, it is recommended you use it. Read more about it http://www.infoq.com/news/2015/03/eclipse-optimizer . (Installing/enabling the JRebel optimization is not necessary as that only applies to Java developers)"

I've added the above info to the User Guide.


Also, because Google Code is shutting down, I've moved the DDT project homepage to: http://ddt-ide.github.io/

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

Is there an easy trick to run/debug unittests?

I found the dialog to add additional options for dub, but it
always executes
"dub build"

Copying the failing unittest into main() works, but I'd prefer
another solution :)

My current workaround is to run "dub --test" from the Linux
terminal. Dub compiles the tests and runs them (the second is
unnecessary but does not matter because tests are fast enough).

After that I can click debug in Eclipse and use the nice debug
support.