Re: [RFC] Suggested replacement for specs and switch handling

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Alexandre Oliva wrote:-

> > Why?  (I've lost the gist of this thread).  I agreed that the front
> > end options be split out into a separate file.  Does that address your
> > concerns?
> 
> Not if you pre-compile all of the options at build time, because then
> you'd have to go back and collect all previously-installed front-end
> options, merge them with whatever new front-end you want to install,
> and pre-compile them again.

OK, that's where the disconnect is.  My understanding of what Joesph
and others meant by "drop-in" front ends was referring to the source
tree, not to the run-time environment.  i.e. that we should be able to
add front ends and not have to muck about with anything in the higher
level directory (we are a long, long way from either, anyway).

My main objective in doing this work, besides cleaning up the mess
that is specs, was speed - the driver is very inefficient, and
contributes a non-negligible amount to C compile time (my guess is
3-5%, which I think we can make < 0.5%).  For C++ the ratios are less,
of course, because C++ is a compile-time dog.  If we move to PCH,
however, the driver, proportionally, will be sucking up a far larger
amount of compile time.  [My plans would at least double the speed of
front-end option parsing, which is a lesser but still worthwhile win].

So I have little interest in blowing away the hard-won gains I make
with abundant run-time configurability that slows us down to a crawl
again - at the very least we'd need to build hash tables at run time.
Very simple driver run-time configurability, maybe via reading in a
one-or-two line file, I have no problem with.

If someone has gone to the trouble of compiling a new front end, not
having to re-compile the one or two files that is the driver is very
little gain for a lot of coding effort and performance loss, IMO.

I would also note that no-one else has come up with a comprehensive
plan to improve the current state of affairs, _and_ written some
working code towards it.

Neil.