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

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Oct 6, 2015 at 11:43 PM, Jeff Law <law@redhat.com> wrote:
> 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.

No, I prefer -cp too - diff just too easily makes a mess out of diffs with -u,
esp. if you have re-indenting going on as well.

Richard.

>
>>
>>
>>>  * 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