On 11/03/2015 09:00 AM, Jeff Law wrote:
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 :-)
yeah but in the meantime its an issue. I *think* I can simply provide
to tool with a set of macros to define on the build command whenever it
tries building a file.. we'll see.
It should also be possible to extract, after reduction, a list of
macros that were used in the source file in conditional compilation, but
which never saw a definition in any of the files. THat could also be
useful information. IN fact, that could be a stand alone analysis
pretty easily I think...
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...
ahh opps. it snuck back in over time :-P sorry.
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.
yeah, its just annoying from a more abstract level (and results from a
few of the tools) for rtl.h to have to conditionally include a bunch of
stuff provided by coretypes.h.
jeff
