On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson <stef...@openjdk.org> wrote:
> 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. 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 . > > This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that > those changes can be discussed separately. An alternative is to just that include/ is special, and shouldn't be specified, but then properly sort jvm.h and friends alphabetically, as specified in the Style Guide. I'm fine with either solution, but I really want to remove this half measure that only some of the directory-less include lines are put at the top of the include block. If we are going to have such a special-case rule, then I'd argue that we should come up with a structure that is easy to explain and maintain, and write it down in our Style Guide. ------------- PR: https://git.openjdk.org/jdk/pull/11133
