On Friday, 20 March 2015 at 15:47:09 UTC, Trent Forkert wrote:
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.
It is _supposed_ to be the same, but not necessarily is. Bugs in
CMake generators are not impossible.
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.
And I don't understand why it is not acceptable. dub is de-factor
part of standard compiler toolchain for D. It is developed as
D-Programming-Language organization project and planned for
eventual distribution with compiler. Saying that is unacceptable
as dependency is similar to saying that Phobos is unacceptable as
dependency.
how it can possibly put something that is language specific
there?
Include directories are not language specific, at least not in
CMake.
Sounds like design mistake to me. There is nothing similar
between include directories in C and import paths in D. Even
within D -J paths and -I paths need to be treated differently.
