D-ark corners - algorithms, ranges, and auto ref - best practices guides.

Sebastiaan Koppe mail at skoppe.eu
Wed Jul 24 18:48:08 UTC 2019


On Wednesday, 24 July 2019 at 08:46:18 UTC, aliak wrote:
>> There is one issue with dub that I know of. When you use 
>> dip1000 and use dependencies that don't, things in the 
>> dependency might mangle differently between the lib build and 
>> your project build if they have an extra attribute inferred.
>
> These are the kinds of things I'm afraid of actually. Is that a 
> dub issue though?

It is not a bug. It is just a result of compiler flags, inferred 
attributes, templates and separate compilation.

The problem comes about because a template from a dependency - 
which is compiled without dip1000/25 - is instantiated in your 
project - which is compiled with dip1000/25 - and then that 
template calls code from the dependency, where different 
attributes are inferred in each compilation. (an attribute 
changes the mangling).

The easiest solution is to use the sourceLibrary target type for 
the dependency, if the dependency is dip1000/25 compatible. Which 
it really should be. Unless it is doing complex stuff, in which 
case, it really should be.

I don't know. I suppose dub needs to propagate dip flags to all 
dependencies. But there are downsides to that as well.

> Also if the depdendency is not dip1000/dip25 compatible (Which 
> i assume - maybe incorreclty - that most are not) then what? 
> Have you encountered much of that?

If you aren't using templates from the library that also call 
into the library, there is no issue. Otherwise, either 
pull-requests to the library or no dip1000/25.

I guess we just need to get dip1000/25 on by default as quickly 
as possible. But the problem is going to surface again when there 
are other feature flags that (in)directly influence mangling.


More information about the Digitalmars-d mailing list