Make dub part of the standard dmd distribution

[Nick Sabalausky via Digitalmars-d]

On 06/10/2015 08:11 AM, Sönke Ludwig wrote:
> Am 04.06.2015 um 17:47 schrieb Atila Neves:
>>
>> I don't know if fragmentation would be an issue. The packages are still
>> dub packages and I for one will use dub.json/sdl to list my dependencies
>> even if reggae is actually generating the build.
>
> Yeah that would definitely not be an issue. I just fear (maybe
> unnecessarily) that people might start to put packages in the registry
> that can *only* be built using Reggae (or some other build tool). At
> least for libraries that would really be bad.

I've found the opposite to be true.

We can *already* get packages in code.dlang.org that work with a custom 
buildscript, but then fail when doing "dub build". I know this because 
I've *already* done it by accident multiple times. And then I get bug 
reports of "X or Y build problem under dub".

But if we can easily tell dub via dub.json, "Hey, don't use your 
internal build system to build this, I've stuck the appropriate command 
in pre/postBuildCommands", then "dub build" will automatically just 
simply work. Major bonus compatibility points the more information we 
can pass from dub to the custom command (ex: "Which 'built type' did the 
user request with '--build='?" or...well, everything provided by dub 
describe --data).

Remember, libraries do NOT need to use the same build system to be used 
together. As long as there's a common interface to...

1. Trigger a build, and

2. Get the lists of import paths and output binaries (and maybe any 
other required flags),

...then everything's golden. This is the job of a package manager. Each 
library author tells the package manager:

1. "When someone asks you to build me, here's how you do it" and

2. "When someone asks you for my import paths and output binaries 
(etc.), this is what you tell them...".

For DUB, #1 above can be done via pre/postBuildCommands as long as we 
can tell it "Don't go trying to build this yourself". (I'm wondering if 
"targetType": "none" would help here.) And for #2, DUB can do that via 
my --data= pull request.

Ok, only one possible issue left: Source libraries (as opposed to binary 
libraries) *could* be an issue just because of the differences in 
collecting the list of files to be compiled. But that's solvable two ways:

1. If your lib *requires* something like RDMD-style dependency 
collecting, then the lib must be a binary lib.

Or much, much better yet: 2. Option in dub.json to say "when you collect 
this package's list of source files, do it RDMD-style". Sure, that may 
not be appropriate for ALL packages, but that's exactly why it'd be a 
per-package OPTION.

And there it is, the *existing* issues of splitting the dub ecosystem 
are thus eliminated, without creating new splits.