<AWT Dev> [OpenJDK 2D-Dev] Fwd: Need reviewers: more predictable binaries
kelly.ohair at oracle.com
Thu Sep 6 19:52:10 UTC 2012
Typically, the macros COMPILE.c, COMPILE.CC, and COMPILE.m will include $(CPPFLAGS)
which is the preprocessing flags for any compilations using a preprocessor.
I was trying to make the minimum changes needed to get this additional -D option on all the
compile lines. I am pretty sure this works, but the way I have changed the sources, if I missed any,
then the worse case is that you still get __FILE__.
It has been suggested that at some point the "#ifndef THIS_FILE" be removed and we expect THIS_FILE
to be defined on all compiles, but initially I wasn't willing to be so strict on this.
On Sep 6, 2012, at 11:42 AM, Mike Swingler wrote:
> My strong suspicion is that the JDK Makefiles only use CFLAGS, not CPPFLAGS for .m files. CPPFLAGS should be used for .mm files (but those should be really rare).
> Mike Swingler
> Apple Inc.
> On Sep 6, 2012, at 11:35 AM, Scott Kovatch <scott.kovatch at oracle.com> wrote:
>> I feel like I should be able to find the answer to this, but does Objective-C use CPPFLAGS? I can't tell if these changes would apply to .m or .mm files. It certainly appears to be the intent of the change, since a number of .m files in the AWT were changed to use THIS_FILE.
>> -- Scott K.
>> On Sep 6, 2012, at 9:30 AM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>>> Just FYI...
>>> these build changes do touch sources in various teams, please let me know if you have issues with these changes.
>>> Begin forwarded message:
>>>> From: "Kelly O'Hair" <kelly.ohair at oracle.com>
>>>> Subject: Need reviewers: more predictable binaries
>>>> Date: September 5, 2012 9:08:53 PM PDT
>>>> To: "build-dev at openjdk.java.net build-dev" <build-dev at openjdk.java.net>
>>>> Need a reviewer for this change.
>>>> It does change source, but it's effectively a build change.
>>>> The goal here is to try and create more predictable binary files and remove the possibility that
>>>> a full source path (via __FILE__) gets baked into the shared libraries or executables shipped.
>>>> So two changes:
>>>> * sort the .o files during links so they are always provided to the linker in the same order.
>>>> * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled
>>>> The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler
>>>> and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files
>>>> will always have a consistent string literal in them, making it easier to compare binaries between builds.
>>>> Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough.
>>>> The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in
>>>> macros but it only will get evaluated in the source file being compiled. It is rare that macros using
>>>> __FILE__ will get expanded in include files and I detected this not happening in the jdk source at all.
More information about the core-libs-dev