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?