On 10/05/2015 09:27 AM, Bernd Schmidt wrote:
On 10/02/2015 04:22 AM, Andrew MacLeod wrote:
The patches are generated by a pair of tools.
* gcc-order-includes goes through the headers and canonically
reorders some of our more common/troublesome headers and removes any
duplicates. This includes headers which are included by other
headers. (ie, obstack.h can be removed as a duplicate if bitmap.h is
included already.)
* remove-includes is the tool which tries to remove each
non-conditional header file and does the real work.
Is the bitmap/obstack example really one of a change that is
desirable? I think if a file uses obstacks then an include of
obstack.h is perfectly fine, giving us freedom to e.g. change bitmaps
not to use obstacks. Given that multiple headers include obstack.h,
and pretty much everything seems to indirectly include bitmap.h
anyway, maybe a better change would be to just include it always in
system.h.
Its just an example of the sort of redundant includes the tool removes.
And your assertion turns out to be incorrect... bitmap.h is barely used
outside the backend, thus it is included in the backend.h aggregator
(This is the only header now which includes bitmap.h... Most of this
many-month effort was to untangle all those indirect includes.)
There are only 6 remaining uses of bitmap.h in all the front end
files. ( Most files can get obstack.h from tree.h. (it comes from
symtab.h in tree-core.) If they don't get it there, it often comes from
diagnostics-core.h.)
I don't see the point in leaving redundant #includes in the source
code because of direct uses from that header in the source. I'm not
even sure how I could automate detecting that accurately.. Going
forward, If anyone ever makes a change which removes a header from an
include file, they just have to correct the fallout. heh. Thats kinda
all I've done for 4 months :-) At least we'll have grasp of the
ramifications..
I'll have a patch shortly to add these and some other useful tools to a
header-tools directory in contrib.
How soon? It's difficult to meaningfully comment on these patches
without looking at how they were generated. Two points:
within the next day, im just cobbling together some minimal
documentation. Dunno how much that will help reviewing the patches
tho. the include reduction process was described in more detail earlier
in this project.
* diff -c is somewhat unusual and I find diff -u much more readable.
unsual? I've been using -cp for the past 2 decades and no one has ever
mentioned it before... poking around the wiki I see it mentions you
can use either -up or -cp.
I guess I could repackage things using -up... I don't even know where
my script is to change it :-). is -u what everyone uses now? no one
has mentioned it before that I am aware of.
* Maybe the patches for reordering and removing should be split, also
for readability and for easier future identification of problems.
I was trying to avoid too much churn on 550ish files... I didn't think
each one needed 2 sets of check-ins. It could be done, but it will
take a while. The reordering patch can be quickly generated, but the
reduction on all those files will take the better part of a week.
My theory is it perfectly safe to back out any single file from the
patch set if we discover it has an issue and then examine what the root
of the problem is..
tool patch coming shortly... probably tomorrow now.
Andrew
