On Thursday, 4 September 2014 at 18:11:47 UTC, Thomas Mader wrote:
On Thursday, 4 September 2014 at 10:39:34 UTC, Idan Arye wrote:
On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader
wrote:
Wouldn't it be better if all this functionality you build in
a vim only solution be integrated into DCD instead?
This way all sorts of compilers and maybe IDEs would benefit
from it and AFAIK there is already a request for DCD to add
dub support.
I already suggested it to Brian a year ago. That was his
answer:
http://forum.dlang.org/thread/icfphxuqhctbqnlgl...@forum.dlang.org#post-fxtqrnpshsnrpiumkzmh:40forum.dlang.org
That was before DUB became the (de-facto) official build
system so he might change his mind, but right now Dutyl
actually
https://github.com/Hackerpilot/DCD/issues/85
OK, so Brian moved from not caring *for* that feature to not
caring *about* the feature - probably because now we do have a
de-factor standard build system. Still - it won't happen unless
someone implements it and it won't be Brian because he is
focusing on making DCD's(and Dscanner's... and libdparse's in
general) parsing abilities even more awesome.
benefits from DCD's lack of DUB support, since it means you
can rely on manual configured file for non-DUB projects.
I don't see why the manual configured file support needs to be
removed if DCD would support dub.
Wouldn't it be possible to change it to a coexisting solution?
As long as DCD retains the ability to manually register the
import paths Dutyl will keep working, but if it didn't I might
have not created the config-file module and the DUB module.
At any rate, Dutyl's architecture makes sure to prevent the DCD
module from knowing where it got the import paths from, to
prevent the config-file and the DUB module from knowing what will
be done with the import paths they provide, and to prevent the
completion function from knowing which modules provided the
import paths and which tools provided autoocompletion(currently
only DCD can provide autocompletion, but the architecture still
forces the completion function to be agnostic about that).
This means that if DCD ever gets DUB support, I'll have to either:
1) Hack the architecture and break agnosticism to make Dutyl use
the dub.json for import paths in autocompletion in DUB projects.
I obviously don't want to hack my own architecture in order to
break the agnosticism rules I set myself...
2) Make the import gathering lazy, and add a special path for
taking configuration from any project file. This will require
some serious changes to the architecture so it'll take the most
work, but it'll retain it's tool agnosticism.
3) Ignore DCD's DUB integration and keep providing the import
paths manually.
Since parsing out the import paths from `dub describe` is blazing
fast, I think I'll remain with the third option - so in the end I
couldn't care less if DCD gets DUB integration.
