I just created a dub package. Frankly, the whole thign is backward.

[H. S. Teoh]

On Wed, Apr 27, 2022 at 07:23:16AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 27/04/2022 7:15 AM, Alexandru Ermicioi wrote:
> > On Tuesday, 26 April 2022 at 18:47:44 UTC, H. S. Teoh wrote:
> > > Well, so it looks like the time is ripe to break dub out of its
> > > original limitations and extend its scope to other languages. (And
> > > other build-like tasks, in general. ;-))
> > 
> > Would be nice if it will use plugin based arch, so that even
> > currently supported features could be extracted into plugins, just
> > like gradle or maven if you're from java world, and be easy for the
> > public to add additional custom functionality as plugins to it
> > without messing the internals.

Totally.  A plugin-based system like gradle would work.


> Right now shared library support is simply not at the level required
> to do this.
[...]

But why does a plugin system need to be based on shared libraries?

Why not expand dub's DSL to be able to encode the kind of functionality
needed to write external plugins, then rewrite existing functionality in
terms of that DSL as a plugin?  Then others can also write plugins in
the same DSL, and you wouldn't need to recompile dub just to add a
plugin.  Just download the plugin description file into some standard
dub directory, and dub would pick it up upon startup.

It's really not that complex.  At the core of it, dub has two main
functions:

1) Package management.
2) Building packages.

I don't think (1) needs to be touched; aside from some performance
optimizations and usage streamlining, dub does a decent enough job
already; the core logic doesn't need to be changed.

For (2), currently there's a lot of hard-coded functionality that's
specific to D. But at the core of it, it essentially boils down to a
build graph consisting of sources (currently D source files) and targets
(currently D executables / libaries) as nodes, and commands that
transform sources into targets (currently invocations of the D compiler)
as edges.

All that's needed is to factor out this underlying build graph structure
and make it a generic build graph resolution system, and rephrasing the
D-specific parts in terms of this generic code in a built-in plugin.
Then expose external interfaces for specifying build graph nodes and
edges to external plugins.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge