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

[Piotrek via Digitalmars-d]

On Friday, 18 March 2016 at 15:31:26 UTC, Dicebot wrote:
>> 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.

I think that std.build could be up to 10KLOC so the compilation 
time would be not relevant.

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

Thanks for explanation. Then let me quote Teoh's great 
description of a practical build tool:

"I think a good balance can be drawn between providing enough 
primitives that cover almost all conceivable use cases in a build 
tool, and at the same time provide an "escape hatch" into a 
full-fledged programming language for those rare but inevitable 
cases where you need to go outside the box and do what the 
designers didn't anticipate."

IMO this applies to all of compiling, configuring and fetching 
sources or binaries and their dependencies.

I'm aware it's not possible to cover all use cases. But 90-95% is 
achievable. The rest is relatively easily to be covered by custom 
d code.

I started that

Piotrek