`determistic` flag and `-include_lib` attribute

[robertoaloi]

When the deterministic option is used to compile a file, the content of the -include_lib attribute is reduced to the basename of the included header. In the case of multiple header files having the same basename but belonging to different application, this creates ambiguity in the Beam file.

Example:

-module(my_module).
-include_lib("app1/include/my_header.hrl").
[...]

Where app1/include/my_header.hrl contains:

-include_lib("app2/include/my_header.hrl").
[...]

Then:

> compile:file("my_module.erl", [deterministic, binary, ...]).
[...]
     {attribute,{1,1},file,{"my_header.hrl",1}},
     {attribute,{1,1},file,{"my_header.hrl",1}},
     {attribute,{9,1},file,{"my_header.hrl",9}},
[...]

For tools that rely on those attributes, this is problematic since it's unclear what my_header refers to (the one in app1 or the one in app2?).

Is this something that can be somehow addressed?

[TD5]

the content of the -include_lib attribute is reduced to the basename of the included header

I haven't validated this is true, but if it is, it seems like the current behaviour is incorrect, but I can see how it would easily happen.

I think the current behaviour is incorrect because of the issue raised above, and the fact that the include_lib path isn't a fully qualified, arbitrary path, but a relative one to the code:lib_dir/1 of the library implied by the path. As such, there's no need to modify it in deterministic mode, because it already avoids capturing incidental environmental effects (such as an absolute path).

I imagine this issue came about due to overzealous basename-ing of paths when deterministic is enabled (perhaps an issue I introduced when expanding the effect of +deterministic?)

[TD5]

Expanding on this, here's a test I wrote a while ago, and the comment seems, if nothing else, overly conservative by only taking the basename of an -include_lib when generating a -file attribute:

https://github.com/erlang/otp/pull/5965/files#diff-f52a51fe09a5ad3cfdd11f09d913a24964ff973579b664ca69b5b1c8f66dd5a2R137

We could safely include the complete path in source code given to -include_lib, and at the same time, make sure that same relative path is plumbed properly into the include file resolution. I think that would resolve this issue.

[jhogberg]

I think the current behaviour is incorrect because of the issue raised above, and the fact that the include_lib path isn't a fully qualified, arbitrary path, but a relative one to the code:lib_dir/1 of the library implied by the path. As such, there's no need to modify it in deterministic mode, because it already avoids capturing incidental environmental effects (such as an absolute path).

-include_lib tries to act as -include first, only using code:lib_dir/1 if that fails, so this assumption won't hold if someone's used -include_lib when they really meant -include.

I'll see if we can remove this weird fallback behavior in OTP 27.