Header-Only Library - pragma(root)

[Mathias LANG]

On Wednesday, 17 June 2020 at 02:51:20 UTC, Adam D. Ruppe wrote:
> On Tuesday, 16 June 2020 at 13:27:00 UTC, Mathias LANG wrote:
>> If I check it out as "arsd-v1.1.1", suddenly it breaks, unless 
>> I use two DMD flags to solve the situation (-I and -mv).
>
> Which is required in ALL cases by the dub approach, you just 
> don't notice it as much because `dub build` sets all that based 
> on the settings in the dub config file (or their conventional 
> defaults).

Not quite, only `-I` is required, not `-mv`, which is fair IMO, 
and expected from anyone familiar with C[++].

> But you lose something there: optional modules are compiled in 
> by dub (unless you go through the config process to separate 
> it), whereas with dmd -i they would not be processed at all.

I totally agree that the current situation on that regard is 
terrible, although that's more of a dub limitation than something 
inherent to the hierarchy.
`dub` has a concept of `mainSourceFile` and I hope one day it'll 
use this to drive compilation instead of selecting all files. I 
have a somewhat related bug report: 
https://github.com/dlang/dub/issues/1778

> It is also impossible to mix versions of dependencies with the 
> dub approach; you can rename that directory to -v1.1.1 but put 
> in a -v1.2.1 next to it and you just have trouble (which is why 
> dub resolves it down to just the one compatible version, or 
> fails if it can't find one...)

I don't quite see how that relates to the discussion. I was 
merely stating that relying on the external name of the directory 
was much worse than having the user pass `-Iproject_name/source` 
by command line.

Nonetheless, I don't see why you would ever want to mix two 
semver-incompatible versions of the same library. I get that it 
can happen due to transitive dependencies, but there's really no 
way to make it foolproof for non-trivial cases, and I think 
everyone's time and energy are best spent avoiding this situation 
than catering for it.

> Maybe one of these days I'll actually write my competing 
> package manager and demo all this stuff (you wouldn't even have 
> to change your layouts btw since it is easy to auto-scan 
> packages for D modules and rearrange them as needed; my doc 
> site does exactly this).


Contributions to `dub` are welcome, will be immediately available 
to users, and will benefit the community much more than yet 
another package manager (we have `dub`, `dud`, `reggae`, and 
probably a plethora of other tools).