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.oh...@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.oh...@oracle.com> >> Subject: Need reviewers: more predictable binaries >> Date: September 5, 2012 9:08:53 PM PDT >> To: "build-...@openjdk.java.net build-dev" <build-...@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 >
