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, like if it was built using dub since the beginning and not with make, or at the very least both.

Good, what's you plan to get every project restarted from scratch using dub?

On Mon, Apr 25, 2022 at 04:05:10PM +0000, deadalnix via Digitalmars-d wrote:
> 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, like if it was built using dub since the beginning and not with make, or at the very least both.
> 
> Good, what's you plan to get every project restarted from scratch using dub?

One ideological struggle I have with dub is that it imposes its worldview upon your project, instead of fitting itself into what already exists, like many other systems do.

I've worked with integrating software with OS package managers, for example, and they often involve simply adding some files, or maybe a subdirectory or two, to your existing source tree, and the packaging tools pick it up from there.  None of them involve mandatory, dictated-from-above reorganization of the source tree structure to fit its ideals (such a thing would have quickly become too onerous to use -- people would just give up trying to cater to the system, and the repository would just stagnate from a dearth of people who are willing to go far enough to satisfy its whims).

Or take the old workhorse Make, which everybody (including myself) hates. It does not require you to reorganize your source tree to fits its worldview; all it needs is to add a Makefile with the right contents, and it Just Works(tm).  The same can be said for a multitude of other Make-replacement build systems.

But not so for dub. It demands that you conform to its conventions, otherwise it flat out doesn't work (or refuses to).  It doesn't play well with external tools: it's theoretically *possible* to invoke other tools if you ask really nicely, but it's glued on as an afterthought, the core design obviously does not acknowledge such usage.  It does not support customization -- you either do things its way, or the highway.

And most importantly of all -- it does not integrate nicely with existing codebases that are already working with a different system. This is especially bad for a small ecosystem that's trying to grow. When the hurdle to adoption involves such efforts as restructuring your entire danged source tree to fit dub's completely (and needlessly) arbitrary requirements, guess how many eager projects are rushing to contribute.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On Monday, 25 April 2022 at 17:07:18 UTC, H. S. Teoh wrote:

> I've worked with integrating software with OS package managers, for example, and they often involve simply adding some files, or maybe a subdirectory or two, to your existing source tree, and the packaging tools pick it up from there.  None of them involve mandatory, dictated-from-above reorganization of the source tree structure to fit its ideals (such a thing would have quickly become too onerous to use -- people would just give up trying to cater to the system, and the repository would just stagnate from a dearth of people who are willing to go far enough to satisfy its whims).
>
> Or take the old workhorse Make, which everybody (including myself) hates. It does not require you to reorganize your source tree to fits its worldview; all it needs is to add a Makefile with the right contents, and it Just Works(tm).  The same can be said for a multitude of other Make-replacement build systems.
>
> But not so for dub. It demands that you conform to its conventions, otherwise it flat out doesn't work (or refuses to).  It doesn't play well with external tools: it's theoretically *possible* to invoke other tools if you ask really nicely, but it's glued on as an afterthought, the core design obviously does not acknowledge such usage.  It does not support customization -- you either do things its way, or the highway.


dub does *not* require you to use a specific structure for your source tree. It has a default that it looks for if none is specified ("source" or "src" subdirectories), but you have options to set it up however you'd like with the directives "sourcePaths", "sourceFiles", and "importPaths". You can output your binary to "targetPath" and use "workingDirectory" to specify where the executable should be run. It's missing a "libPaths" directive, but you can set that up for specific linkers via "lflags".

On Monday, 25 April 2022 at 14:48:47 UTC, drug wrote:
> On 25.04.2022 07:54, norm wrote:
>> On Saturday, 23 April 2022 at 20:15:27 UTC, deadalnix wrote:
>>> So, I have this nice little project, sdc. It builds using make, and everything was good. People wanted it to be distributed via dub, so be it, let's create a dub.json file.
>>>
>>> [...]
>> 
>> At my company we use Conan for D because the majority of code is C++. Our D projects are Conan packages using Makefiles or CMake, just like our C++ projects. It is a pity D decided to try and reinvent package management when there are battle hardened options already available that are flexible enough to just work with D.
>> 
>> Conan is NOT perfect but to date it has just worked and is much easier when integrating D with C/C++ code and mixed build systems.
>
> Dub is much more easier than conan (we use it all over the place). Although conan works with binary artifacts in contrast to dub working with source code so dub and conan can't be compared easily.

Conan works with either packaged binaries or packaged sources. I think the comparison is valid. I also disagree that dub is easier. Sure it is much simpler to get started for trivial projects but with any non-trivial project you end up hitting its walled garden pretty hard.