Re: [RFC] Include file structuring.

[Andrew MacLeod <amacleod at redhat dot com>]

On 10/18/2013 12:55 PM, Jeff Law wrote:
> On 10/18/13 08:00, Andrew MacLeod wrote:
> > The question is... Do we allow a .h file like this to be an aggregator,
> > meaning a file can just include tree-ssa.h and get all this, or do we
> > push it all down to the .c file, and actually include what each one
> > needs.  Or do we pick a specific subset for tree-ssa.h...
> I thought we had decided we weren't going to allow this -- ie, if you 
> need ssa-iterators.h, then you include it rather than assuming you get 
> it from tree-ssa.h.

Well, we specifically disallowed prototypes from some other .c file 
being in a .h..  ie,  file.h is to have only the prototypes for file.c 
in it.

I don't think we ever discussed/decided what an include file should or 
needs to include from other include files...  but I could be wrong :-)

> > So far I've removed the less commonly included files, ie, less than 10
> > or so .c files need it.  That also gave me the opportunity to analyze
> > and restructure the exports in those files a bit. That is a much larger
> > job on these commonly included files, so I don't plan to do that sort of
> > analysis.  Yet anyway.
> >
> > Current practice is that every .c file should start with
> > #include "config.h"
> > #include "system.h"
> > #include "coretypes.h"
> Yes.  Let's just go ahead and set this in stone now.
>
> I know someone will argue that if they're the same, then there should 
> be an aggregator which includes all three so that each .c file doesn't 
> muck it up.  I see their point, I just prefer to move to a more 
> explicit model.
Yes, one can argue that the "implementation" file, be it tree.h gimple.h 
or rtl.h could include these very things... since ultimately, we'd need 
one of these 3 files to start every .c file.


> > I also think every .c file should also then have
> > #include "tree.h"
> > #include "gimple.h"    // Only assuming it is a gimple based file
> >
> > These are basic implementation files and I think it's reasonable for
> > each .c file to include them as a basis if they are to be used.
> Well, presumably you're talking about files that care about trees. 
> Ideally we'll get to a place where the RTL optimizers (for example) 
> don't have to include tree.h.
indeed.  at the moment, every file needs trees.  When I work on the 
wrappers, tree.h will be trimmed out of those files which get 
converted.   rtl will also at the point only require some aspects of 
gimple (the symtabs and whatever else we discover), and  presumably have 
an rtl.h that those files include.

The point being, after those first 3 files, the .c file should include 
whichever "implementation" files it requires... be it tree.h, gimple.h 
and/or rtl.h.  Eventually, it will only be one of those 3.  I hope :-)


> > At a minimum, I do think that if a .h file *requires* another .h file to
> > compile, that it should include it.  ie, if gimple-ssa.h is included, it
> > wont compile unless tree-ssa-operands.h has already been included, so
> > that seems reasonable to include directly in gimple-ssa.h. Otherwise
> > ones needs to add the file,  compile, and then figure out what other
> > file you need.  That seems silly to me.
> It's a bit silly, but does result in a minimal set of #includes :-)  
> Or it results in folks just including a bunch of headers because they 
> copied them from somewhere else.

perhaps...  As I was writing up my argument for why this #include in the 
includ efile is good, I convinced myself of the opposite :-P

If we follow this and include other files which are required by this .h, 
some files will indeed be included many times.  In particular, most of 
the tree-ssa*.h files which include inline functions are going to need a 
certain subset of other ssa.h files, like operands, iterators, etc.  So 
this path slowly leads to include aggregators again...

So I retract that comment.   I think perhaps no include file should 
include any other include file...  and the C files can order them. The 
worst case we end up with is too many includes in a .c file... and that 
can be addressed.

I have already created a little tool that runs through the source base 
removing each include one at a time from a .c file and checking if it 
still compiles ok.   I was saving that to run for a bit later once I 
have things a bit more processed... maybe in a week or two. I did a dry 
run last week and it removed 600+ include's from just the middle/backend 
.c files :-P.   we could easily run that just before ending every stage 
1 to clean things up a bit.  (it also ends up removing duplicates... 
you'd be surprised how many times the same file appears in the include 
list file :-)

That should at least help with the cut'n'paste approach that we've all 
used to get a .c file started :-) Just use 'em all and get the tool to 
reduce it for you!

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 :-)
> > Perhaps using that as the guideline, we should just push all includes
> > down into the .c files?  I think I favour that approach.
> To the extent possible, I favor this as well.  Mostly because I see 
> this as an early pass filter when we look at modularity problems, both 
> in existing sources and in future patches.
Next week I will try this with tree-ssa.h. I'll try pushing the .h files 
out to the .c files and see how that works in practice.  Maybe that will 
help clear things up a little.

Andrew