Re: [patch 0/3] Header file reduction.

[Jeff Law <law at redhat dot com>]

On 10/05/2015 02:10 PM, Andrew MacLeod wrote:
> > 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.
It may not be the best example.  The tools don't treat obstack specially 
(nor should they IMHO).  So let's pretend it's not obstack.h which has 
been arguably a core part of GCC for a long time.

>    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..
And the last sentence is the key here.  We're trying to get to a point 
where we can make certain kinds of changes, then have the compiler spit 
out errors, fix the errors and have a high degree of confidence that the 
final change is correct and that we've found all the places that need to 
change.

The change could be as simple as moving a function declaration to its 
natural place, collecting interfaces & data into classes, or something 
more ambitious like removing trees from the backend.  Folks will note 
that these are all refactorings that we don't want to change any 
observable behaviour.





> >  * 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.
I'm probably the last person in the world that still generally prefers 
-cp :-)  I'm getting to the point where I can tolerate -u.


> >  * 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.
I haven't looked at the 3 patches in detail yet.  Given my familiarity 
with the overall process/goal, I can probably handle them as-is. 
They're just big mechanical changes.

jeff