DDT 0.11.0 released

[Trent Forkert via Digitalmars-d-announce]

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.