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.
Jeff