On 20/03/2015 18:07, Trent Forkert wrote:
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

That's the lamest reason ever. Why is that an issue? Just install it if it is not installed. To me, that's akin to saying DDT shouldn't have a requirement of the Java VM!

  * Because anybody not using dub should not be required to use dub.
This is dlang, not dublang
  * Because I just want to tell Eclipse about the project, there is no
need to involve dub
  * Because the user said so

These are basically all the same reason: "me no want to use dub!". Well, you're free not to use DDT either!

Seriously, I don't understand the *gripe* here: DUB offers a service, a functionality, that is not offered elsewhere (for D at least): a package management system, for source packages. And this is an important functionality for language ecosystems, because it is so damn useful!! That's why nearly all modern language have a source-package manager (Rust - Cargo, Ruby - rpm, Go - `go get/install`, Java - Maven/OSGi), all of them integrated with a build tool. I hope your experience/mindset has not been too tainted with archaic C/C++ paradigms that you fail to see this.

D actually lags behind these languages in that DUB is not an official part of the language/toolchain. Although from what I recall there are plans to make DUB included as part of the DMD installation, so that would change.

>   * Because it is at odds with C/C++ integration, which is an H1 priority

This is the only reason with some credence. However, *not using dub* doesn't makes DDT automatically integrate with C/C++, nor doesn't it even necessarily bring it any closer to that. A fair amount of work would still need to be done to properly support this scenario, I suspect.

Bruno Medeiros

Reply via email to