On 10/23/2015 11:11 AM, Jeff Law wrote:
> On 10/23/2015 06:24 AM, Andrew MacLeod wrote:
>>
>> Hmm. yeah,   It was mostly intended to show you what structure you have
>> and are getting indirectly, not so much indicate that you actually
>> include things directly twice.    It utilizes a common function which
>> returns unique header files (find_unique_include_list) and just
>> processes those.  A quick tweak should resolve that to just linearly
>> parse and process.
> It may not be worth the trouble.
>
> There were maybe a half-dozen files with repeated direct includes and 
> they stood out as not being as mechanical as the others (with respect 
> to reviewing the changes).  I suspect that in the future it won't 
> happen much, if at all, and we won't be looking at 15k line patches to 
> clean things up.
>
>>
>> It also occurs to me the reason you only found one options.h in the
>> previous note... show-headers probably didn't know where to look for
>> your build directory to delve into tm.h.   It defaults to ../../build
>> which is what I use.  I will also tweak that to attempt to automatically
>> find a build directory below ../..  and failing that, have you 
>> specify one.
> Yea, I almost asked about procedures for the tool to find tm.h as it 
> was relatively common for tm.h to include something indirectly and 
> make later stuff redundant.  But after a while, I got pretty good at 
> knowing what was in tm.h and how that would effect what headers became 
> redundant as tm.h got included earlier (via target.h).   Similarly for 
> optabs.h moving around and making other stuff redundant.
>

Apply this diff to the contents of contrib/headers

Duplicates are now treated as they are seen instead of ignored.
Rather than hardcoding ../../build/gcc, the tool now makes an attempt to 
find a "gcc/tm.h" from ../..   It will print a message if it fails to 
find one.  In which case you can use -i to specify a directory to look in

Andrew