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
> * 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.