Re: [PATCH] Speed-up get_identifier("main") (take 2)

[neroden at twcny dot rr dot com (Nathanael Nerode)]

Zack said:
>No.  As Andrew pointed out downthread, a configure test will not work,
>because it will get the wrong answer in stages 2 and 3 of a bootstrap.  
Hopefully this will be fixable in a trivial way once bootstrap is moved
to the top level.  Like so many other things.

I'm still working on that, by the way.  :-)

The difficult part is really stupid.  The different copies of GCC 
have separate gcc/include directories.  Although these have identical 
files in them, the different pathnames screw up the 'compare' stage of 
the bootstrap.  (Yes, I have solved all the other filename problems 
affecting the 'compare' stage, and quite simply, too.)

My desired solution is to cause only one build of the gcc/include 
directory.  (Or two, but one should be easier.)  

I've been approaching this by trying to pull fixincludes/fixproto/fixheader, 
and the other include file generators run at build time, into a separate 
toplevel directory, since that's the most elegant solution.  (At that 
point, how many times it operates can be decided by the top level with 
no trouble.)  Since this is non-trivial, I've been trying to impose as 
much simplification as possible on the fix* architecture before doing 
so.

Several parts of fixheader, and probably parts of the generation of 
limits.h, could easily (and better) be folded into fixincludes.  Except 
that currently these parts are run even when the stupid alternate 
fixinc.svr4 script is run, so that would be a regression on SVR4.
(The no-fixincludes targets are also a minor issue, but I believe they 
will turn out to generally not need the applicable parts of the machinery,
and anyway it would be straightforward enough to mark certain fixes as 
'*really* for everyone'.)

So I've been trying to collapse fixinc.svr4 into regular fixincludes.
This is an infuriating project given the absence of people who actually 
have SVR4 systems to test on.  At least someone volunteered to help me 
with DYNIX/ptx, so I can get *that* one right.  But when I finish that, 
I'm probably going to ask for svr4 to be flipped over to regular 
fixincludes despite the lack of testing.  Or for generic svr4 support to 
be dropped, due to the clear lack of interest.  :-P

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html