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

[Ola Fosheim Grøstad]

On Tuesday, 26 April 2022 at 20:29:54 UTC, Steven Schveighoffer 
wrote:
> No amount of ImportC is going to encompass building all 
> existing C projects.

Yes, I of course agree with this, but one could make it a goal to 
only require thin shims that require minimal amounts of 
maintenance. If you only require thin shims then some sort of 
collaborative effort could go a long way to keep it up to date 
(e.g. you create a partial shim for your project and I improve on 
it when I need it).

It does require some organizing efforts though.

> But if you can all find a way to build dub projects in a way 
> that's usable outside building with dub (e.g. `dub 
> --produce-makefile` or whatnot), that's fine by me. Just don't 
> make me change how I build my projects.

Ok, but the question is what the official strategy ought to be. 
Should official strategy be to roll-your-own (Dub etc), or should 
it be to build on what others have created.

Where do you get more bangs for the bucks? By pouring resources 
into your own corner of the universe or by enhancing an existing 
system to have solid D support (e.g. Conan, Cmake etc).

There is a marketing issue too. For newbies, Dub and "idiomatic" 
packages might be the best option. If you want to win over 
experienced developers, maybe Cmake/Conan or some other 
comparable setup focusing on brining in existing frameworks would 
be more convincing.

What is the target audience? People who want to stay in their own 
corner of the universe and build something unique and easy to 
use, or people who want to engage with the larger software field?