H. S. Teoh
Posted in reply to rikki cattermole
| 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.
|