On 18 October 2013 19:16, Andrew MacLeod <amacl...@redhat.com> wrote:
> So I think I am in favour of no includes in .h files... It may make it more > obvious when a file is using some other inappropriate file for something, > and it is easier for my simple analysis tools to find poor export > candidates. > > I will also note that our list of 3 to start the file would now become: > > #include "config.h" > #include "hwint.h" > #include "system.h" > #include "coretypes.h" > > since system.h currently includes hwint.h :-) In the case of header files that have to be included by every .c file, it does not help with fixing modularity/dependency issues to force the .c files to include all the dependencies of the header file, even those that don't define any interfaces of their own (as opposed of ones used solely by including header files, or being part of the interface definition of the including file) that are to be used by the .c files. It might make sense to break up system.h into different files to group specific features together, or to break up config.h to include files generated in different parts. The choice of a monolithic header file or an include tree are implementation details of the header file, yet with the rigid no-include-includes policy, we force these implementation details into each consumer .c file.
