dub -> meson

Atila Neves atila.neves at gmail.com
Wed Apr 17 08:45:50 UTC 2019


On Wednesday, 17 April 2019 at 06:43:35 UTC, 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.

I considered this; I even named the project. However, after I 
read this:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwjNgZLl3dbhAhXN66YKHXbEBkEQFjAAegQIBBAC&url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fuploads%2Fprod%2F2018%2F03%2Fbuild-systems-final.pdf&usg=AOvVaw2j71hXjOoEQLNNjvEOp_RQ

I'm not sure just describing a DAG is enough. I've started 
playing about with the same concepts in D here:

https://github.com/atilaneves/rocksteady

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

This might not always be possible. First, because of what I said 
above, and secondly, the feature sets sometimes don't match. I 
had to give up trying to express some concepts in the reggae tup 
backend because they're not doable there. And ninja requires 
modifications to the compiler that I solved by writing a compiler 
wrapper.

> 2.1 Replace dub's current execution code with this new core 
> while keeping backwards compatibility with existing dub projects

I'm already doing that.

> 2.2 `dub build` consists of two general steps: 1) fetching 
> dependencies

Which has nothing to do with building and should be done as a 
separate step.

> 2) building each project in the set { dependencies..., 
> top-level project } in topological order.

The builds are independent, they should be done in parallel.

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

This would work for many build requirements, but not all.

> What do you think? Are you willing to help with the design 
> and/or implemention on this initiative?

Already doing it.




More information about the Digitalmars-d mailing list