DUB - call to arms

Guillaume Piolat first.last at gmail.com
Tue Apr 16 15:52:57 UTC 2019


On Tuesday, 16 April 2019 at 12:12:45 UTC, Atila Neves wrote:
>
> I'll take a look. In the meanwhile I started this:
>
> https://github.com/kaleidicassociates/bud
>
> It uses dub as a library to make sure that it works just as dub 
> does, but bypasses what it can. The idea is to completely 
> separate these disparate tasks:
>
> * Dependency version resolution (from dub.{sdl,json} -> 
> dub.selections.json)
> * Fetching dependencies that are not already in the file system 
> (trivial after dub.selections.json has been generated)
> * Extracting information from dub about source files, import 
> paths, etc.
> * Actually using the information from dub to build
>

Won't complain about such good news!

dub.json and dub.selections.json must unify though, as 
dub.selections.json is not self-sufficient, what if they 
contradict themselves?


> In the future dub.selections.json will have to be fixed to have 
> different entries per configuration, and possibly per platform 
> as well. Fortunately there's a version field in the current 
> format. I'm currently concentrating on assuming that 
> dub.selections.json is generated and taking it from there.

I'm not really sure which are the original DUB assumtions.

I think our research concluded that solving dependencies for a 
particular platform+configuration is (in an idealized DUB) a 
fundamentally different operation than generating a proper 
dub.selections.json (for which you would have to find a super-set 
for "all conf"). The problem is that configurations/platform 
could appear and disappear alongside previous versions.


(For readers: this would lead the path to platform-based 
dependencies and configuration-based dependencies which are 
currently not doable, such as:

     "dependencies-linux": { "x11": "~>1.0" }
)



More information about the Digitalmars-d mailing list