DUB - call to arms

[H. S. Teoh]

On Wed, Apr 17, 2019 at 03:48:36AM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 4/16/19 1:39 PM, H. S. Teoh wrote:
[...]
> > I was thinking the build/test/etc. command can itself be defined by
> > a dependency.  For example, if your project uses make for builds,
> > there could be a `make` dub package that defines command-line
> > templates used for generating platform-specific build commands. Your
> > package would simply specify:
> > 
> > 	"build-system": "make"
> > 
> > and the "make" package would define the exact command(s) for
> > invoking make [...etc...]
> 
> Interesting idea. I definitely like it, though I would consider it not
> a "basic fundamental" mechanism, but rather a really nice bonus
> feature that provides a convenient shortcut for having to specifying
> certain things manually...IF you happen to be using a buildsystem
> known by the package manager...or (better yet, if possible) a
> buildsystem that's able to tell the package manager enough about
> itself to make this happen.

The idea behind this is that in order to avoid baking in support for a
multitude of build systems (make, scons, meson, gradle, whatever) into
dub, which will inevitably be unmaintained and out-of-date 'cos is too
much work to keep up with everything, we delegate the job to individual
packages.  There would be one package per external build system, e.g., a
'make' package for make support, an 'scons' package for scons support,
and so on.  These packages don't have to do very much, all they need is
to (1) define a way of installing said build system, in a way that can
be used by dub via a standard interface, and (2) export various
command-line templates that dub will use for invoking the build system.

So for example, the 'make' package might contain a bunch of URLs for
downloading a 'make' executable and any associated libraries and data
files, and then export `/path/to/dub/cache/bin/make` as the command
template for invoking the build system.  There could be OS-dependent
variations, such as `C:\path\to\dub\cache\make\gmake.exe` if you're on
Windows, for example.  These command flavors are defined within the
'make' dub package, and then any project that uses make can just declare
a dependency on 'make', and dub will know how to do the Right Thing(tm).
Dub itself wouldn't have to know the specifics of how to work with a
make-based source tree; it will just execute the commands defined by the
'make' dub package.


[...]
> > If done correctly, dependency resolution is just a topological walk
> > on a DAG.  Get this right, and everything else falls into place.
> 
> Yes, but therin lies the rub - "getting this right". AFAICT, Sonke
> seems to have a very good grasp on dependency resolution via DAG (or
> at least, certainly a far better grasp than I do). But yet, even his
> algorithms in DUB, he needed to occasionally patch with
> common-use-case short-circuiting logic (and I don't even know what
> else) just to fix various seemingly-infinite-loop issues (not
> technically infinite, but appeared to be to the user) that people were
> still reporting some years into DUBs lifetime.
> 
> 'Course, if it really is simpler than it seems to me (and *especially*
> is it *isn't*), then I'd certainly be more than happy to delegate
> dependency resolution out to somebody else.

It would help if somebody can provide a concrete example of a complex
dependency graph that requires anything more than a straightforward
topological walk.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.