On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via
> 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 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
Take my gunroar 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.
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