Re: [RFC] Include file structuring.

[Andrew MacLeod <amacleod at redhat dot com>]

On 10/22/2013 08:27 AM, Joern Rennecke wrote:
> 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.
I would expect that when we eventually get everything sorted out, the 
implementation files will simply include these "required" files,  so 
most .c files will probably start with only one of:
#include "tree.h"  or  #include "gimple.h"  or #include "rtl.h"
and get all the "basics" that are required.  that would be nice... :-P

> 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.
I think this is transitional. Its such a mess right now, that I think we 
need to flatten the entire thing, and then rebuild it with some modular 
design in place such that routines and data structures are where they 
belong. then we can consider including things that are prerequesites.

I don't think we'll live by a draconian rule of "no include shall ever 
include another include"...  but we need to at least head in that 
general direction to figure out what bits are where and who requires them.

Andrew