On Wed, Apr 2, 2025 at 4:15 AM Jason Gunthorpe <j...@nvidia.com> wrote: > > On Wed, Apr 02, 2025 at 03:46:34AM +0900, Masahiro Yamada wrote: > > However, it is annoying to make every header self-contained > > "just because we are checking this". > > From my POV itis not "just because we are checking this", I have a > very deliberate reason for wanting headers to be self contained: > > I want the clangd code indexer and editor integration to work fully. > > When clangd is asked by the editor for a report on a header file it > cannot know the missing implicit includes and it's functionality is > degraded. It reports fake compilation errors, can't do all the > indexing functions, and is generally a bad experience. To be clear the > header is parsed and loaded into the database when some C file > included it, just the actual editing of the header doesn't work well. > > This is a very big day-to-day negative for working on the code. I'm > frequently annoyed by headers that are pointlessly not self > contained. I'd really welcome someone doing a cleanup here. > > I agree it should not be a hard rule. I was reading the thread you > linked to and I'm thinking the approach is not optimal. > > The only header files that should be checked are ones that are > actually used as part of the build with the current kconfig. Christoph > is right that there are endless cases where headers should never be > parsed outside of specific kconfig settings. > > So, I'd suggest a better way to run this is first build the kernel, > then mine the gcc -MD output (ie stored in the .XX.cmd files) to > generate a list of headers that are actually part of the build, then > only test those. That eliminates all the kconfig problems. Opt out any > special headers that really have a good reason not to be stand alone.
Sounds much better. -- Best Regards Masahiro Yamada
