dub -> meson

[rikki cattermole]

On 17/04/2019 6:43 PM, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 16 April 2019 at 16:42:24 UTC, H. S. Teoh wrote:
>> On Tue, Apr 16, 2019 at 06:13:30AM +0000, JN via Digitalmars-d wrote: 
>> [...]
>>
>> What we really need is a dub replacement that has a different, more 
>> flexible design that can accomodate things that people want to do, 
>> that the current dub simply cannot due to its design limitations.  
>> There are some promising ideas in the other thread about improving 
>> dub, and I hope that discussion will eventually lead to a redesign / 
>> revamp of dub that makes it more viable for my use case.
>>
>>
>> T
> 
> IMO, the best course of action is:
> 1.0. Create a generic foundation based on DAG for describing targets and 
> their relations.
> This can start as a completely independent project with zero dependencies.
> 
> 1.1. On top of this core functionality we can add an interoperability 
> layer that allows exporting this abstract representation to other build 
> system formats.
> 
> 1.2. We can reuse the existing build systems written in D as a build 
> backend.
> 
> 2.0. Integrate the new build system foundation in Dub 2.0:
> 
> 2.1 Replace dub's current execution code with this new core while 
> keeping backwards compatibility with existing dub projects
> 
> 2.2 `dub build` consists of two general steps: 1) fetching dependencies 
> 2) building each project in the set { dependencies..., top-level project 
> } in topological order. (Of course there are many other (sub)steps, 
> which I'm mentioning here for simplicity.) Now that in 2.1 we replaced 
> Dub's existing execution code with the new build foundation we have the 
> option to not execute those steps directly, but instead use Dub as a 
> meta build-system which can generate build description for other build 
> systems to execute.
> 
> 2.3 Allow describing complex builds based on the foundation layer. This 
> can be done either declaratively, directly in dub.json / dub.sdl, or dub 
> can call to a D script that generates a JSON describing the build 
> dependencies that the core described in 1.1 can read.

That's going to require a ton of work and refactoring.
But it would be well worth funding after "1.0".