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

Erik Joelsson erik.joelsson at oracle.com
Fri Nov 30 18:44:26 UTC 2018

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 "THISFILE" is always empty which of course makes builds to various locations highly comparable :) On the other hand, HotSpot is not using THISFILE 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 "THISFILE" instead of getting rid of "THISFILE"? 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

More information about the build-dev mailing list