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

[Joern Rennecke <amylaar at redhat dot com>]

> > I think it's nicer for front ends to be able to be separate.  We want it
> > to be possible, in principle, for a separate front end not to have a tight
> > version dependency on the rest of GCC, but just to be able to have the
> > subdirectories added and work, if it uses the documented interfaces.  If
> > it needs a patch to a central options file, such a patch is bound to
> > conflict with changes to the central file between releases.
> 
> I agree.  Imagine a distant future where the front-end is a dynamically
> loaded module.  A key means of managing complexity for front-end
> developers is that they should not have to know about one-another;
> if there are ways that the Java guys can affect the C++ front-end,
> or vice versa, that's bad.

I second that.  I'll go even further and say that we should keep the
ability to do basic flag passing and modification runtime-configurable.

And I also have an idea how this acn be made to work without the
overhead of specs.

We could have a configuration directory where all the text input files
are installed, with bits in the filename that show what part of the
compiler they belong to, and parts that can show an order / priority,
akin to sysv configuration files.

When a new frontend gets installed, its options configuration file gets
installed in the config directory, and the next time the compiler
driver is invoked, it notices that the directory has changed, and
re-builds the has lookup tables and table of data encodings, which
it stores in a data file.  In a unix-like system this would be done
be executing a suid compiler-owner program, so that the datafile
belongs to the compiler owner. (Obviously you have to have write
acess to the config directory before you can effect a change in
the datafile).

The numbers passed to the frontend should be arrived at only by the
information that is in its own spec file, to avoid problems when
driver and front end have a version skew.  So the driver might have
its own unified numbering for the options, but if so, it translates
them in those that the frontend can understand.

Likwise, small changes to the default options passed to the compiler,
or where to find linker scripts, can be made by dropping additional
files in the config directory; the change of the directory would then
force a datafile rebuild.  If you change a file, you'd force a rebuild
by touching the directory or by invoking the driver by hand.