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

[Kelly O'Hair]

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.

-kto

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).
> 
> 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/1ff2eb00/attachment.html