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

[Hildo dot Biersma at morganstanley dot com]

>>>>> "Joern" == Joern Rennecke <amylaar@redhat.com> writes:

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

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

In our environment, the location were applications are compiled is
at a different location from where applications are installed and run
- and the installation environment is a read-only, replicated
filesystem. Systems that rely on run-time modification of
configuration files cannot be deployed in such an environment.

In addition, the scheme proposed makes it really hard to back out an
installed upgrade.  I actually prefer each release having its own
independent configuration files, specifically for this reason.