On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stef...@openjdk.org> wrote:
> The sorted blocks of includes have deteriorated to the point that I felt > compelled to clean up some of the issues. > > One of the more prevalent issues is that files in src/hotspot/share/include > are not properly sorted. There has been some discussion that that was done on > purpose, but it just adds another exception to the include rules that don't > have any practical purposes, IMHO. It also goes against our written style > guide around include files. One argument why it was OK have the files in > include/ pushed up to the top of the sorted block, was that the file was > included without specifying a directory. That's an argument that contradicts > how we treat platform-dependent files, which (unfortunately) often also are > specified without a prefixed directory, so I don't think that's a good enough > argument, again IMHO. To remove this special case, I've removed the > extraneous make file entry to have src/hotspot/share/include in the set of > directories to search for headers when compiling HotSpot. Now all the header > files in src/hotspot/share/include gets included by specifying the path from > src/hotspot/share, just like the other platform-independent headers in HotSpot. > > While going over the include headers I've also cleaned up surrounding > whitespaces and incorrect include guards. Hmm. Now that "jvm.hpp" becomes "include/jvm.hpp" it seems like it would make sense if the include guard for jvm.hpp reflected the relative file path, like most other files. I noticed that its current include guard is `#ifndef _JAVASOFT_JVM_H_`. When I search for "javasoft" I get no hits. I guess it isn't obvious if we can change it without introducing build issues for users out there? So maybe it should remain the way it is anyway. ------------- PR: https://git.openjdk.org/jdk/pull/11108
