This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Include file structuring.
- From: Joern Rennecke <joern dot rennecke at embecosm dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC <gcc at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, Diego Novillo <dnovillo at google dot com>
- Date: Tue, 22 Oct 2013 13:27:11 +0100
- Subject: Re: [RFC] Include file structuring.
- Authentication-results: sourceware.org; auth=none
- References: <52613EED dot 2080800 at redhat dot com> <52616801 dot 8000302 at redhat dot com> <52617AFF dot 60509 at redhat dot com>
On 18 October 2013 19:16, Andrew MacLeod <amacleod@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.