On Tuesday, 26 April 2022 at 18:14:20 UTC, H. S. Teoh wrote:
>
> 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.

So, perhaps dub itself should be used as part of your more general build system to build D code only?
Perhaps, there should be some integrations of of dub with other popular tools, so such use would be less painful.
That is ofc, in case you want your code available for others to use where you work, or by public.

On Monday, 25 April 2022 at 11:18:57 UTC, bauss wrote:
> This discussion would never have happened if the project was just created with dub in mind from the beginning,

I started with dub for all raylib projects, got annoyed with the lack of multi executables per project that share several files like oh idk type definitions without the whole song a dance.

Replaced it all with 150 lines of code. Dub doesn't narrow opinions on organization dont fit everyone.

Dub bad, I should have listened to the wise adr sooner

On Tuesday, 26 April 2022 at 18:47:44 UTC, H. S. Teoh wrote:
> Well, so it looks like the time is ripe to break dub out of its original limitations and extend its scope to other languages. (And other build-like tasks, in general. ;-))

Would be nice if it will use plugin based arch, so that even currently supported features could be extracted into plugins, just like gradle or maven if you're from java world, and be easy for the public to add additional custom functionality as plugins to it without messing the internals.

On 27/04/2022 7:15 AM, Alexandru Ermicioi wrote:
> On Tuesday, 26 April 2022 at 18:47:44 UTC, H. S. Teoh wrote:
>> Well, so it looks like the time is ripe to break dub out of its original limitations and extend its scope to other languages. (And other build-like tasks, in general. ;-))
> 
> Would be nice if it will use plugin based arch, so that even currently supported features could be extracted into plugins, just like gradle or maven if you're from java world, and be easy for the public to add additional custom functionality as plugins to it without messing the internals.

Right now shared library support is simply not at the level required to do this.

Dmd is the biggest lagger atm. But seriously export is a real design problem. I really dislike it affecting visibility when it is a linker directive.

On 27/04/2022 7:27 AM, Ola Fosheim Grøstad wrote:
> None of these approaches work, because the core problem is that the eco system is too small to sustain a secure package system detached from the rest of the world. I would never use it. Too dangerous and exploitable. One big security vulnerability that I don't want to think about.

Unless we build literally everything in D, people will continue to ship their own binaries for platforms such as Windows. So that their library/binding "just works".

But in saying that, you do raise a good point. A long term strategy may be to require only our CI to build + upload binaries. This would make it reproducible since its script based.

On Tue, Apr 26, 2022 at 07:06:50PM +0000, Alexandru Ermicioi via Digitalmars-d wrote:
> On Tuesday, 26 April 2022 at 18:14:20 UTC, H. S. Teoh wrote:
> > 
> > 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.
> 
> So, perhaps dub itself should be used as part of your more general build system to build D code only?

But why would I even need dub when the more general build system also handles building D code just fine?  Unless the boss dictates that I absolutely have to use dub *somewhere*, just for the sake of using dub, then it's just a redundant gear doing what other gears are already doing. Might as well economize and take it out completely.


> Perhaps, there should be some integrations of of dub with other popular tools, so such use would be less painful.

If we want more widespread adoption of dub, I would say this is absolutely essential.


> That is ofc, in case you want your code available for others to use where you work, or by public.
[...]

The problem right now is, even if I want my code to be available to others, dub may not be able to do it.

E.g., if part of my D source files is autogenerated from data files using an auxiliary utility (also written in D), then dub wouldn't even know how to build such a thing. I can call dub from my build system and it'd work, but anyone else who uses dub to download my package would not be able to use it because dub doesn't know how to build it, and that person would not know to run another build system to make it work.

To make it work, I'd have to jump through lots of hoops and write a whole bunch of extra scripts to be called from dub's "preBuildCommands", that essentially duplicates what my other build system is already doing. It's a lot of redundant bending over backwards just to work around dub's limitations.  Unless my boss is holding a gun to my head and demanding that I make it work, the chances of me putting in this effort is nil.

Dub needs to expand its horizons and break out of its own walled garden.


T

-- 
Time flies like an arrow. Fruit flies like a banana.