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
