Make dub part of the standard dmd distribution

[Sönke Ludwig via Digitalmars-d]

Am 04.06.2015 um 17:47 schrieb Atila Neves:
>> On a related note, it's also a pity that Reggae mixes incremental
>> build improvements (from which DUB itself could greatly profit, too -
>> just as a Ninja generator for DUB would be a nice feature) with a
>> separate, layered build description. I mean there is of course no
>> reason to not have alternative approaches for build descriptions
>> available in general, but when mixed with a public package repository,
>> it just leads to fragmentation.
>
> I can add a ninja generator to dub if you want, with the default being
> per-package compilation (since right now for dub it's one file or
> everything at once).

That would be great! If the per-package mode has such practical 
benefits, we could also simply make it the general default, for all 
generators that can support it. However, I just briefly looked at your 
benchmark results, the performance boost seems to be solely because of 
parallel compiler invocations. We already had issues with per-module 
parallel compilation and out-of-memory errors, so this optimization 
seems to be only suitable for certain projects or build machines. So at 
least with the current compiler memory requirements I'm not sure if this 
would be a good default build mode.

>
> But I wrote reggae because:
>
> 1. Declarative is preferable but imperative is needed. My (our?)
> favourite imperative language is D, so I want to specify builds in it.

This is of course perfectly fine and reasonable (although I personally 
find the D syntax to be a bit too verbose for this task, but thats 
really just personal taste - oh, and JSON is awful, too ;). The problems 
just start to creep in as soon as public DUB packages start to depend on 
Reggae - then we'll possibly get another split in the ecosystem. I'd say 
we should generally try to focus on a single standard solution, however 
that looks and however the tool is split into executables or packages.

> 2. I want a build tool that builds on dub but doesn't require it

Fair enough.

> 3. I wanted it to make it easy to link with C and C++

This really also needs to be solved within DUB (i.e. without resorting 
to preBuildCommands). That is going to be the next priority after 
getting the 1.0.0 features ready.

>
> As I've mentioned before, I know the kind of things I'd want to do with
> the build system if I had a large and complicated enough project, and I
> know I wouldn't be able to do it easily using dub alone. As I've also
> mentioned before, building with dub is just fine for most people.

Getting some of those use cases on a Wiki page or something would be 
great. There have been some ideas to approach the procedural aspect from 
a different angle - using procedural DUB plugins that can be invoked 
from within the declarative build description. This would have the 
advantage that a lot of information can be gathered about a package 
without executing procedural code (with the possible accompanying 
security risks and performance issues or the efforts needed to mitigate 
those).

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