<AWT Dev> [OpenJDK 2D-Dev] Fwd: Need reviewers: more predictable binaries

[Mike Swingler]

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).

Regards,
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.
>> 
>> -kto
>> 
>> 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.
>>> 
>>>   http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/
>>> 
>>> 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.
>>> 
>>> -kto
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120906/7d8ee707/attachment-0001.html