Make dub part of the standard dmd distribution

[Nick Sabalausky via Digitalmars-d]

On 06/01/2015 10:49 AM, Jonathan M Davis wrote:
>
> Even simply splitting dub out so that it can pull in packages without
> necessarily being able to build them would be nice (maybe adding a flag
> to the dub.json file indicating whether dub can be used as a build tool
> for the project or whether it's supposed to just act as a package
> manager for it), though that does add the problem of code.dlang.org
> becoming more confusing, since you wouldn't be able to rely on all
> projects on it being built for you by dub as part of the process of
> grabbing packages.
>

I've brought up something like that, but it was met with very strong 
opposition. :(

> It's a complicate problem, and dub went a route which works in the 90%
> case, but doesn't work for more complicated cases, which will make dub
> unusable for some projects - especially corporate ones. I don't know how
> fixable it is without a major redesign of dub.

Personally, I think "90%" is generous here, but I admit that's splitting 
hairs.

Unfortunately, "less than 100%" is a big problem in this case because 
those libs/projects that don't fit the "90%" effectively cannot even 
participate in the dub repository for others to use (at the very LEAST, 
they get pounded with "fails to build via dub"). So NOT using dub to 
build is freaking viral.

And *using* certain dub-based projects inside one which doesn't build 
via dub can be a major pain, as anyone who's tried to use vibe.d from a 
non-dub-based project should be able to attest (just *try* to figure out 
all the -I... and linker flags you need *and* double-check/maintain them 
every time you upgrade vibe.d).

So anything less than 100% effectively splits the whole damn ecosystem. 
NOT acceptable.

Dub's project generation feature is NOT a solution here, because you 
still have to manage builds dub's way, *exactly* as if you were using 
dub's build system, because...really...you still ARE. So all the 
dealbreakers for those 10+% projects still apply equally.

On the plus side though, I *do* think this is basically solvable. The 
most immediate way (and what I'm working towards) is to create a 
dub.json that feeds dub a 'dummy-src/dummy.d' to keep dub's build system 
happy and safely away from the real source files, and then use:

"(pre|post)-build-command-posix": "./my-real-buildscript"
"(pre|post)-build-command-win": "my-real-buildscript"

To trick dub into using a different build tool.

It'd be easily to design/publish a skeleton dub.json to do exactly that. 
(Kinda sucks to NEED that, but at least it'll work, and once it's in 
place them maybe it can be made easier. The non-buildsytem parts of 
dub.json really ARE very trivial, and if someone had a problem with even 
that trivial little bit, then I don't see how they could develop any 
useful software in the first place.)

I'm fairly certain the ONLY real thing still preventing all that above 
from actually working is that dub currently provides no (practical) way 
to retrieve the necessary compiler/linker args in order to actually use 
your dependencies (again, try using vibe.d in, say, an rdmd-based 
project). I say no "practical" way here because "dub describe -> parse 
the JSON -> extract the needed info -> convert the needed info to 
compiler flags" is NOT exactly practical or reasonable to expect people 
to do *just* to use RDMD or otherwise opt-out of dub's build-system.)

Again though, I'm working on that:

https://github.com/D-Programming-Language/dub/pull/572

That lets you directly grab any build info you need from dub. My next PR 
will then let you ask dub to automatically format the output for your 
compiler's CLI. And then one last one to provide convenience switches 
for the most likely configurations (like 
"--just-gimme-whatever-flags-I-need-to-pass-to-rdmd-so-I-can-actually-use-my-dependencies", 
but obviously less verbose :))

With all that, any project should be able to participate in the dub 
ecosystem AND opt-out of dub's build system WITHOUT segregating the 
ecosystem in any way.