Idea: std.build instead of dub and make-like tools

[Dicebot via Digitalmars-d]

On 03/17/2016 06:42 PM, Piotrek wrote:
> On Thursday, 17 March 2016 at 15:49:07 UTC, Dicebot wrote:
>> On 03/17/2016 07:15 AM, Piotrek wrote:
>>> As for dub I don't think it is unrelated. Why std.build couldn't be
>>> dependency manager?
>>
>> For same reason you don't want to distribute any other non-trivial
>> tools as sources :) Compilation takes time and has non-trivial
>> dependencies (i.e. networking libraries, git providers etc.), you
>> simply can't put that stuff as a stdlib module/package and expect
>> developers to compile it each time.
> 
> Hmm, the build module could be compiled once. It sources are supposed to
> stay unchanged, right?

Even "once" will be too much for majority of D users (those who are not
also Gentoo users at least :D). Remember - we are not speaking about
build as simple as `rdmd std/build.d` at this point, it will have
numerous additional dependencies, including linker dependencies. And has
to be perfectly cross-platform.

>> Tight coupling of dependency management and build tool in one entity
>> is just too inflexible. This is single biggest issue I have with dub
>> in its current form.
> 
> Can you explain it by example (I don't mean dub problems, which I agree
> exist, but the inflexibility in general)?
> I can't see a conflict between the two functionalities.

Typical example - we use custom Makefile based framework for internal
Sociomantic D projects, one which is much more capable than existing dub
build support and works decently for our needs overall. There is no way
it can be replaced with dub at its current state. However using the very
same dub to fetch sources of 3d-party libraries and ensure version
compatibility is something quite desired.

When build tool and package management system are packed into one tool,
you pretty much need for both to be perfect to match everyones desires.
And that is simply impossible.