<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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).</div><div><br></div><div>Regards,</div><div>Mike Swingler</div><div>Apple Inc.</div><br><div><div>On Sep 6, 2012, at 11:35 AM, Scott Kovatch &lt;<a href="mailto:scott.kovatch@oracle.com">scott.kovatch@oracle.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>-- Scott K.</div><div><br><div><div>On Sep 6, 2012, at 9:30 AM, Kelly O'Hair &lt;<a href="mailto:kelly.ohair@oracle.com">kelly.ohair@oracle.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div>Just FYI...</div><div><br></div><div>these build changes do touch sources in various teams, please let me know if you have issues with these changes.</div><div><br></div><div>-kto</div><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica; font-size: medium; "><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"Kelly O'Hair" &lt;<a href="mailto:kelly.ohair@oracle.com">kelly.ohair@oracle.com</a>&gt;<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica; font-size: medium; "><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Need reviewers: more predictable binaries</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica; font-size: medium; "><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">September 5, 2012 9:08:53 PM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family: Helvetica; font-size: medium; "><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"<a href="mailto:build-dev@openjdk.java.net">build-dev@openjdk.java.net</a> build-dev" &lt;<a href="mailto:build-dev@openjdk.java.net">build-dev@openjdk.java.net</a>&gt;<br></span></div><br><div><br>Need a reviewer for this change.<br><br> &nbsp;&nbsp;<a href="http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/">http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/</a><br><br>It does change source, but it's effectively a build change.<br><br>The goal here is to try and create more predictable binary files and remove the possibility that<br>a full source path (via __FILE__) gets baked into the shared libraries or executables shipped.<br><br>So two changes:<br> &nbsp;* sort the .o files during links so they are always provided to the linker in the same order.<br> &nbsp;* replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled<br><br>The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler<br>and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files<br>will always have a consistent string literal in them, making it easier to compare binaries between builds.<br>Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough.<br>The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in<br>macros but it only will get evaluated in the source file being compiled. It is rare that macros using<br>__FILE__ &nbsp;will get expanded in include files and I detected this not happening in the jdk source at all.<br><br>-kto</div></blockquote></div><br></div></blockquote></div><br></div></div></blockquote></div><br></body></html>