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

[H. S. Teoh]

On Wed, Apr 27, 2022 at 05:27:01AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 27/04/2022 5:19 AM, H. S. Teoh wrote:
[...]
> > But doesn't that mean it will lose out on the benefits of having a
> > build system in the first place?  E.g., if the source file for the
> > helper utility wasn't changed, there's no need to run it again. But
> > dub wouldn't know better, since I specified preBuildCommands it
> > would always run it, correct?  So it would rebuild the helper
> > utility every single time?
> 
> Dub is able to cache things.
> 
> In context I don't know how much can be done prevent work, since your
> own tools would need to do caching as well.

Right, which brings me back to square one. Dub already knows how to
cache stuff, but I can't leverage any of it because it was arbitrarily
decided that dub would only work with D source files, and therefore it
only caches D artifacts.  If I want to build HTML files from templates,
for example, I couldn't leverage dub's caching ability; I have to roll
my own and reinvent the square wheel.  If I want to build PNG files from
data files, I'd also have to roll my own cache.  Eventually, I'd want to
avoid reinventing my own cache for every artifact I want to build, so
I'd look for a system that offers me that capability.  Such a system
would obviously also be able to build D programs and cache them as
artifacts, since building D programs would be a specific case of the
more general task of building a target from sources and caching it.
Which in turn means that dub has just become redundant: I might as well
just use that other system for *all* my build needs, including building
D programs, and it would let me do everything I need without needing to
work with two different, overlapping systems (dub + other build system).

That's my current line of reasoning, and why I haven't seriously
invested in dub.


[...]
> Single file packages just like any other package can depend upon
> another by path, rather than version lookup.
> 
> I do this plenty, it works fine. Quite often I swap out to a full
> blown package, since single file packages can't have multiple files in
> it (hence the name).
[...]
> > But why should I need to create a separate package anyway?  The
> > entire reason I build my helper programs from the same source tree
> > is because they logically belong together and complement each other.
> > Why can't I have multiple targets per package, and why can't I use
> > one target to build another within the same package?
> 
> Yes this is a pretty big sticking point.
> 
> By in large this is a genuine issue that I believe needs resolving.

Whether dub ends up implementing this or not, there is a larger picture
I feel is being missed here.

Even if dub eventually allows building multiple executables from
different subsets of the same source tree, that's still limited to only
D artifacts.  It still doesn't allow the user to leverage its dependency
resolution, building, and caching capabilities for non-D artifacts.  If
I were to adopt dub at that point, I'd still have to roll my own
dependency management, building, and caching for non-D artifacts.  Which
would drive me to use a different build system that *can* offer me those
capabilities. Which in turn makes dub a redundant factor in the
equation.

Strictly speaking, dependency resolution isn't specific to building D
programs.  There's no technical reason why it should be limited only to
D.  Similarly, building a D program is merely a more specific instance
of the general task of transforming a set of input files into one or
more output targets by running some command (compiler in the case of D,
but I seriously doubt dub actually cares what executable is being run in
the place of the compiler, as long as it produces the expected outputs).
Caching is also a general concept that isn't tied specifically to
compiling D programs.

These general capabilities are arbitrarily restricted in dub, for
whatever reason, to only building D artifacts. As a consequence, dub is
unable to handle many things which, given the algorithms that it
*already implements*, it ought to able to handle.  The user is unable to
leverage these algorithms, which dub already uses internally, to other
tasks in his project.  This imposes arbitrary limitations on dub and
forces users to seek for more general solutions.

If there was a way to remove these limitations from dub so that it can
be used for more general build needs, I would be happy to use it.  But
as things stand, it's not meeting my build needs.


> However in 10 years I haven't needed it, I only just recently got
> around to improving shared library support so it actually worked as I
> needed that ;)

I'd be happy to contribute toward making dub more general, like I
outlined above.  But my current perception is that the dub maintainers
aren't interested in moving in this direction. I'd be happy to be proven
wrong, though!


[...]
> > > Upgrade only might be a good addition however.
> > 
> > Doesn't dub already do this? Or am I not understanding this right?
> 
> I don't know. I don't use this feature.
> 
> https://github.com/dlang/dub/issues/2244

I think I'm missing something here. How does "upgrade only" relate to
the our present discussion?


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.