On Friday, 20 March 2015 at 15:52:18 UTC, Dicebot wrote:
It is _supposed_ to be the same, but not necessarily is. Bugs
in CMake generators are not impossible.
Of course not, but I prefer a build system that works 99.99% of
the time regardless of where it is used over a build system that
can only be used on one machine or software stack.
And I don't understand why it is not acceptable.
* Because it is not guaranteed to be there. For instance, I
don't have dub on my system
* Because anybody not using dub should not be required to use
dub. This is dlang, not dublang
* Because it is at odds with C/C++ integration, which is an H1
priority
* Because I just want to tell Eclipse about the project, there
is no need to involve dub
* Because the user said so
dub is de-factor part of standard compiler toolchain for D.
No it isn't. Neither is rdmd. Nor is make part of the standard
compiler toolchain for C. When CDT uses make it does so *because
it was told to*. Same with ninja. VisualStudio project generation
doesn't use makefiles, because it is generating a VisualStudio
project.
And the fact that a whole bunch of abandoned single-module D
libraries use dub is irrelevant when people like me, Manu, etc
are working on larger, more complicated projects and say
(repeatedly!!) that dub doesn't meet our needs.
It is developed as D-Programming-Language organization project
and planned for eventual distribution with compiler.
rdmd is already distributed with dmd. Is it now a required part
of the build process for all projects?
VisualD is also developed under D-Programming-Language. Is it now
required as well? Why isn't DDT using a .visualdproj?
Saying that is unacceptable as dependency is similar to saying
that Phobos is unacceptable as dependency.
I'm not saying Phobos is unacceptable, but there are those that
do. However, phobos is a library, not a build tool. Apples,
oranges, etc.
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.
It's a list of directories. Sure, the compilers might do
different things with the directories, but I've never encountered
any harm from there just being a single list of directories to
look for includes/imports in.
Even within D -J paths and -I paths need to be treated
differently.
My fork handles -J paths separately from -I paths:
include_directories(foo) # -Ifoo
include_directories(TEXT bar) # -Jbar
Similarly, CMake also handles regular vs system include paths for
C/C++ compilers:
include_directories(SYSTEM baz) # -isystem baz
However, D doesn't have a -isystem, so SYSTEM is effectively
ignored when producing the flags for a D compiler.
