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.kova...@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.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 >>> >> >
