Re: [RFC] Let's kill specs, completely rewrite gcc.c

[Per Bothner <per at bothner dot com>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> Per Bothner wrote:-
> 
> > Can we separate out the table of options from gcc.c and place it
> > in a separate file so toplev.c etc could use it?  This file might also
> > include some of the utility routines, like the function that does a
> > binary search on an option name.
> 
> How would you propose handling the fact that the full table would have
> combined cpp / C / linker / assembler options (plus C++ / fortran
> etc. specific ones)? 

We need the full table for gcc.c.  I don't see how having the same full
table also available for use by toplev.c (and fornt-end options parsing)
changes that.

The table of options should probably be constructed at configure or
make time from lang-specific pieces, and sorted at make time.

> It would probably also need some target-specific
> options; I've not got much experience in that area.

Likewise.  In other words:  I don't really know how this is handled now,
in gcc.c, but some equivalent mechanism can be designed, and if so
why can't the lang front-ends use the same mechanism?

One possible concern:  If gcc reads options from an external file,
we could have the front-ends do the same - but at the cost of an
extra file open.

(Now that we've integrated cpp and the front-ends, the next step
is to integrate the assembler.  After than, we just merge it all
into gcc proper!)

> Maybe we have one master .tab file, for consistency across everything,
> and process it through different scripts at GCC compile time depending
> upon the user?  gcc.c would want a script that combines everything and
> sorts it; other scripts could filter it for whatever toplev.c or
> c-decl.c or cp/decl2.c etc. require?

For example.   Or the front-ends can just use the whole table.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/