[patch 4/3] Header file reduction - Tools for contrib - second cut

[Jeff Law]

On 10/14/2015 09:14 AM, Andrew MacLeod wrote:
> Here's the latest version of the tools for a sub directory in contrib.
> I've handled all the feedback, except I have not fully commented the
> python code in the tools, nor followed any particular coding
> convention...   Documentation has been handled, and I've added some
> additional comments to the places which were noted as being unclear. Ive
> also removed all tabs from the source files.
>
> Ive also updated show-headers slightly to be a little more
> error-resistant and to put some emphasis on any header files specified
> on the command as being of interest . (when there are 140 shown, it can
> be hard to find the one you are looking for sometimes)
>
> Do we wish to impose anything in particular on the source for  tools
> going into this sub-directory of contrib? The other tools in contrib
> don't seem to have much in the way of coding standards.     I also
> wonder if anyone other than me will look at them much :-)
I'm certainly interested in them.

Do you have any sense of whether or not coverage of the tools has 
improved over short time since we started squashing out conditional 
compilation?  I was running the header file reordering bits on the trunk 
and was a bit surprised of how many things they're still changing.  But 
that would make sense if some files are now being processed that weren't 
before because we've squashed out the conditional compilation.

It certainly is true that the total result is smaller than any of the 
backend, config/ or languages changes that you posted, and I'm running 
it across the entire source tree, but I'm still surprised at how much 
churn I'm seeing.

If it weren't for the level of churn, I'd probably be suggesting we just 
have this stuff run regularly (weekly, monthly, whatever) and commit the 
result after a sanity looksie.  I've yet to see this tool botch anything 
and if we're not unnecessarily churning the sources, keeping us clean 
WRT canononical ordering and duplicate removal automatically seems like 
a good place to be.

Maybe do another commit of the reordering output and evaluate again in a 
month?

I don't think we're quite there on the reducer and it obviously requires 
more infrastructure in place to test.  But it'd be nice to get to a 
similar state on that tool.

Which reminds me, you ought to add a VMS target to your tests.  The 
reducer botched vmsdbgout.c.


alpha64-dec-vms
alpha-dec-vms
ia64-hp-vms

Covering any one of those ought to do the trick.

Thoughts?

jeff