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. This seems very disruptive and I'm not sure there is any real gain. From a practical view how does this potentially impact the ability to do clean backports? I don't agree with the changed treatment of `share/include` and I think it looks very strange to see `#include "include/xxx.h"` I agree with Kim it would be better to break this up into different issues so that we don't roadblock on "all or nothing". ------------- PR: https://git.openjdk.org/jdk/pull/11108
