DUB - call to arms

Nick Sabalausky (Abscissa) SeeWebsiteToContactMe at semitwist.com
Wed Apr 17 18:57:05 UTC 2019


On 4/17/19 12:03 PM, H. S. Teoh wrote:
> 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.

I agree, letting build system packages tell the packmangr how to use 
them is definitely preferable to baked-in support.

> 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.

Yes, in general, pre-built binary tool packages that originate from 
outside (or inside) D-land must be supported. This has been one of my 
bigger issues with DUB. And a little bit extra consideration for 
buildsystems in particular is likely warranted.

Only change I would make is that declaring a dependency on a buildsystem 
shouldn't *necessarily* mean that the package manager invokes the 
buildsystem directly. In many cases it would, and could maybe be a good 
default, but it also needs to support the case where a project uses its 
own buildscript and the buildscript invokes something like make or such 
(probably, in this situation, the buildscript would invoke the 
buildsystem - or any other executable tools it relies on - through the 
package manager...or at least through information provided by the 
package manager via envvars, for example).

Another thing to keep in mind is that the interactions between package 
manager and buildsystem will likely require more than just the 
buildsystem telling the package manager "Here are the command(s) you use 
to invoke me". For example, the package manager may need to relay things 
like "Which configuration is being built". Although, now that I think of 
it, since the package manager is banned by charter from being a 
buildsystem, it might not need to pass nearly as much information to 
buildscripts/systems/etc as DUB-as-a-pack-manager would need to.


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

Personally, in the absence of someone like Sonke who's already 
experienced with real-world dependency resolution popping in to help out 
on that, I'd really like to just simply start by adapting and re-using 
some already-established dependency-resolving code, such as from DUB. 
This is one thing I'd really want to avoid reinventing the wheel on if 
at all possible.

--------------------------------

In response to suggestions from NaN and Russel, I'd like to move this to 
a Github project.  No code yet, just because I don't have any yet, but 
we can use the issues/PRs/wiki features to collaborate publicly in a 
more structured, less transient, way:

https://github.com/Abscissa/DPak

@H. S. Teoh: I forget your Github handle. Let me know and I'll add you 
as a collaborator.


More information about the Digitalmars-d mailing list