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
