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