RFR(XS): 8214534: Setting of THIS_FILE in the build is broken

[Erik Joelsson]

Hello,

On 2018-11-30 10:03, Volker Simonis wrote:
> Thanks for the background information. But as far as I can see, this
> currently only works because "THIS_FILE" is always empty which of
> course makes builds to various locations highly comparable :) On the
> other hand, HotSpot is not using THIS_FILE at all and "__FILE__" quite
> a lot.
>
> Don't get me wrong. I highly appreciate the feature of having absolute
> path names in the build to make all command lines in the build
> self-contained (I use that feature every day :). And I also support
> the goal of making builds even more reproducible. But does this goal
> not apply to hotspot (or is it just on the TODO list ?).
>
> In the end, I'm happy with the current, minimal fix which at least
> gets the logs working again.
>
> And maybe for the follow up change we should then better move all
> "__FILE__" occurrences in HotSpot to "THIS_FILE" instead of getting
> rid of "THIS_FILE"?
>
When converting the hotspot makefiles, that was on our list, but we 
never got around to it. The problem with the THIS_FILE approach is that 
it only sets the .c/.c++ file name while many of the __FILE__ in hotspot 
are in header files. This means that the accompanying __LINE__ will be 
incorrect. At the time I didn't feel comfortable introducing such a 
degradation in the usefulness of Hotspot debug messages.

We also have a much harder time with reproducible output in Hotspot in 
general, probably because it's a much bigger library and also because of 
C++ vs C. As it stands now, I couldn't say we have concrete plans on 
changing Hotspot to THIS_FILE other than a vague vision of at some point 
making an effort towards more reproducible builds in general.

A possible different approach could be to back off on the absolute paths 
in the actual compile command lines by actively rewriting all paths 
relative to the source root before calling the compiler, and always call 
the compiler from there. This would preserve the absolute paths 
everywhere in make, but would make the cmdline files a bit less useful 
(though we could still make a copy-paste of the command in there behave 
with "(cd srcroot && compile)" construct.) This may be a better long 
term strategy for truly reproducible builds anyway.

/Erik