Kelly O'Hair (kelly.oh...@oracle.com) wrote: > Yes, but I feel like I need to get some kind of approval from a higher level > before I try and declare that > use of THIS_FILE is a 'jdk convention', and that will trigger long debates :^( > > I also need to deal with hotspot, which is a bit trickier because of the > macros being expanded in include > files (inline method bodies inside *.hpp files).
There is also the fact that the basenames are not unique. Maybe it won't be an issue, but someone should really check. <wear_kevlar_suit> Have you looked at normalizing to the path relative to the repo root? </wear_kevlar_suit> -John > On Sep 5, 2012, at 11:59 PM, Fredrik Öhrström wrote: > > > Looks good. Perhaps we can even remove the "#ifndef THIS_FILE" test in the > > source files? At some time in the future…. > > > > //Fredrik > > > > 6 sep 2012 kl. 06:08 skrev Kelly O'Hair: > > > >> > >> 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 > > >
