I thought about warning just for leaves of the package tree, so e.g. those two would conflict:

somelib.subpack1
somelib.subpack2
somelib.subpack2
somelib.subpack3

But this one wouldn't

somelib.subpack1.subsubpack

What if somelib.subpack1 contained a module named subsubpack? Admittedly unlikely with those example names, but not necessarily in the general case. Also as mentioned in my other post, there are single modules which pull in a complete C library, in those cases it might make sense to actually pack a single module, sharing a D package with other modules/packages pulling in C libraries. Also the check for leaf packages is quite artificial: "Why do I have checks for my leaf packages, but not for my higher level sub packages?"


Another probably better idea would be to only include packages in the list that actually contain modules. That would be a more conservative approach, where it can still be guaranteed that there are no conflicts, but still it should be sufficiently flexible.

I thought of packages containing just modules as leaf packages. If you mean the sub packages of a library, you have the problem that if packages are not named after D packages, that it is not really obvious what those actually are, as not all packages might be installed top level. For example: "org.eclipse.swt" or "somecompany.lib1".

On a different matter, should we also warn about conflicts with -J files?

I tend to say no, because they have a defined override behavior and this is very useful to customize Diet templates of dependencies. A more explicit way would be desirable, but I don't know how that should work without uglifying the API.

How is it defined? I just tried, it seems it is the same as for -I, meaning the first that is specified wins. So dub will simply add the -J paths of direct dependencies before the ones of indirect dependencies?

About uglifying the API, I think if I needed to do this, I would just derive from implementing class and override the method instantiating the vibe template. Wouldn't this work?

But yeah, if this is common practice issuing warnings is useless at best.

Best regards,

Robert