On Thursday, 19 March 2015 at 15:14:09 UTC, Bruno Medeiros wrote:
On 19/03/2015 14:45, Trent Forkert wrote:
It seems you are right that it *is* limited, but it shouldn't
emits include/import paths into the project structure. I had
emitted into .project, but evidently emits into .cproject. If
supported a .dproject I could also emit, I could get it to
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??
1. I don't consider an XML configuration to be "your own file
2. For the very reason that started this entire conversation. Not
everybody *wants* to use dub. Not everybody *can* use dub. So it
doesn't make sense for DDT to force dub.
It would be silly to use anything else.
VisualD has done pretty well for itself.
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.
This still requires dub for things to work, which isn't an
Using XML the way CDT does also allows something else: GUI
configuration. Users could then adjust build parameters via a GUI
the way IDE users would expect to be able to, instead of editing
a configuration file for a tool they aren't even using.