On 11/03/2015 06:24 AM, Andrew MacLeod wrote:
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.
hmm. no, i dont have a feel for that. Anl to be fair, I didn't run the
tools on every file in trunk. I limited it to the ones in backend.h,
and took out even a few of those that were troublesome in some way or
other at some point. I wouldnt expect the conditional stuff to affect
reordering much. reducing... we might start to see things like tm.h or
target.h included less.
Well, the reorder tool will punt if it sees conditional compilation in
the headers, so I was kind hoping that some of the churn would be
explainable by the ongoing removal of conditional compilation causing
files to be processed now that weren't before. But it appears its
other factors.
A further enhancement in line with that would be to teach the reducer
about a couple of special files.. like the relationship between
options.h, tm.h and target.h. sometimes target.h was included when in
fact options.h was the only thing actually needed.. During the
flayttening process I manually handled this by flattening tm.h out of
target.h and options.h into anything that included tm.h... so every
file had options.h, tm.h and target.h explicitly included, and then the
reducer would just pick the "minimum". of course, the reorder tool
works against this by combining them again :-)
A fair amount of the churn was options.h related. I'll run it again and
look closer to see how much exactly.
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.
it can botch one of the go files.. go has a backend.h of it's own...
which buggers things up quite nicely since it doesnt include a bunch of
the headers gcc's backend.h does :-)
Cute.
The reordering tool is likely safer to run across the board.. especially
if we can determine the very small subset it shouldn't be run on.
go, the gen* files perhaps a few others. Blacklisting and running
regularly is probably the way to go then.
Right now it triggers off the presence of system.h... if system.h is not
present, it wont do anything to the file. I haven't tried running it
against *.c to see if there are any other failures, perhaps thats not a
bad idea. That will also provide us with a list of files which have
headers included within conditional compliation... there are a few of
those :-P and maybe they could be fixed. by default it wou=nt do
anything to those either.
I didn't know it keyed on system.h. I'd manually blacklisted testsuite/
but otherwise let it run wild just for giggles. Knowing it keys on
system.h is helpful in that we don't have to blacklist nearly as much stuff.
And yes, there's a few files with conditional headers. It wasn't
terrible and makes a nice todo list for someone new to tackle.
Anyway, if we run it against everything and check it in, then in theory
there isn't any reason you couldnt spot run it at some interval.. there
shouldn't be much churn then.
That's the idea and obviously the more automated the better.
yeah, the reducer still needs some tweaks to be generally runnable I
think. IN particular, how to deal with externally supplied macros it
cant really see. Im still thinking about that one.
Well, the solution is obvious, we continue the move away from
conditionally compiled code so that those macros don't matter in the end :-)
Which reminds me, you ought to add a VMS target to your tests. The
reducer botched vmsdbgout.c.
Thats one of the reasons vmsdbgout.c wasn't in the list of things I
reduced :-)
Ahem, but vmsdbgout.c was part of the commit on Friday...
back to reordering... the gen files are a bit of a pain too because of
the rtl.h conditional inclusions.. which I never really found a good
solution for... maybe we should have a brtl.h which is used in concert
with any source which uses bconfig.h.. brtl.h could verifies bconfig.h
has been included and then includes those headers it needs, followed by
rtl.h itself.. and the tool could confirm the right pairing of
config.h/rtl.h bconfig.h/brtl.h is used. hmm.
I think initially we could blacklist the gen* files. I'm less concerned
about the generators than I am the compiler proper.
jeff
