[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Fwd: Need reviewers: more predictable binaries
From:       scott.kovatch () oracle ! com (Scott Kovatch)
Date:       2012-09-06 18:35:35
Message-ID: 2B5D1C2E-C8CB-424B-8EB7-6056ACB9B1CC () oracle ! com
[Download RAW message or body]

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/2d-dev/attachments/20120906/200adeec/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]