On 10/18/13 08:00, Andrew MacLeod wrote:
The tree-flow.h restructuring now brings us to the larger question of
exactly how we want includes organized. All the remaining includes in
tree-ssa.h are required by numerous other .c files. The actual number of
.c files which will need to #include any given file is:
(roughly calculated by the number of .o file which don't compile when
removed from tree-ssa.h)
19 bitmap.h
77 gimple.h
61 gimple-ssa.h
17 cgraph.h
72 tree-cfg.h
46 tree-phinodes.h
69 ssa-iterators.h
82 tree-ssanames.h
38 tree-ssa-loop.h
37 tree-into-ssa.h
35 tree-dfa.h
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.
ISTM explicit including rather than aggregation makes it clearer to the
reader which modules a particular file has to interact with. And when
we see something "odd" in a particular file's include list, it's a good
indicator that we need to look at little more closely to see if we've
got code in the wrong place or bad separation of components.
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.
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.
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 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.
jeff
