Hi, On 2019-07-31 11:23:22 -0400, Alvaro Herrera wrote: > I think removing unnecessary include lines from header files is much > more useful than from .c files. However, nowadays even I am not very > convinced that that is a very fruitful use of time, since many/most > developers use ccache which will reduce the compile times anyway in many > cases; and development machines are typically much faster than ten years > ago.
IDK, I find the compilation times annoying. And it's gotten quite noticably worse with all the speculative execution mitigations. Although to some degree that's not really the fault of individual compilations, but our buildsystem being pretty slow. I think there's also just modularity reasons for removing includes from headers. We've some pretty oddly interlinked systems, often without good reason (*). Cleaning those up imo is well worth the time - but hardly can be automated. If one really wanted to automate removal of header files, it'd need to be a lot smarter than just checking whether a file fails to compile if one header is removed. In the general case we'd have to test if the .c file itself uses any of the symbols from the possibly-to-be-removed header. That's hard to do without using something like llvm's libclang. The one case that's perhaps a bit easier to automate, and possibly worthwhile: If a header is not indirectly included (possibly testable via #ifndef HEADER_NAME_H #error 'already included' etc), and compilation doesn't fail with it removed, *then* it's actually likely useless (except for portability cases). * I think a lot of the interlinking stems from the bad idea to use typedef's everywhere. In contrast to structs they cannot be forward declared portably in our version of C. We should use a lot more struct forward declarations, and just not use the typedef. Greetings, Andres Freund
