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
