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

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Apr 28 03:48:33 UTC 2022


On Wed, Apr 27, 2022 at 10:20:23PM +0000, jmh530 via Digitalmars-d wrote:
> On Wednesday, 27 April 2022 at 20:38:53 UTC, H. S. Teoh wrote:
> > [snip]
> > This would most certainly lead to very interesting developments. The
> > package management part of dub could be decoupled from the build
> > system, for example, by making build systems part of the dependency
> > system so that alternative build systems can be installed and used
> > directly by dub.  [snip]
> 
> That's been talked about for awhile...maybe it would take someone
> forking dub and just releasing one or the other component.

I've thought about doing exactly this, in fact.  I haven't actually
looked at the code in detail yet, but based on the documentation of the
configuration files, I'm thinking to extend the concept of
configurations to cover non-D build rules.

Essentially, the current concept of a "package" is more-or-less
equivalent to a subgraph in a generic build graph where the inputs are a
particular collection of D source files, and the output is a D
executable or library.  Thanks to dub's built-in backward compatibility
measure of ignoring unknown directives, one could retroactively say that
current packages have implicit settings whose default values are those
that designate the package as a D build, with the current semantics.
When these (new, but retroactively interpreted as implicit) settings are
modified, they change the semantics into non-D builds.  Thus, the
concept of a package can be extended to non-D builds in a backward
compatible way that does not require modifying existing dub packages.

I'm not sure how amenable the current dub code is to this modification,
but worse comes to worst, one can always rewrite this part of the code
from ground up, following the current specifications for the existing
configuration parameters, and adding new parameters with the new
semantics. Possibly reuse dub's test suite to ensure backwards
compatibility.  Or perhaps even the nuclear option of rewriting the code
from scratch while maintaining the ability to parse existing
dub.json/dub.sdl files so that existing packages can transition with
zero change.


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.


More information about the Digitalmars-d mailing list