This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Suggested replacement for specs and switch handling
- To: Hildo dot Biersma at morganstanley dot com
- Subject: Re: [RFC] Suggested replacement for specs and switch handling
- From: Joern Rennecke <amylaar at redhat dot com>
- Date: Wed, 27 Jun 2001 15:43:11 +0100 (BST)
- Cc: amylaar at redhat dot com (Joern Rennecke),mark at codesourcery dot com (Mark Mitchell),jsm28 at cam dot ac dot uk (Joseph S. Myers),neil at daikokuya dot demon dot co dot uk (Neil Booth),gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org)
> 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.
Well, if it's read-only that means you can't do any upgrades or
modifications. So in that case, you'd want to pre-build the driver
data file on the build system, and then cast it in stone or ROM or
whatever.
> 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.
The original scheme didn't allow any upgrades - only wholsale driver
replacements. The scheme I proposed allos to add and remove configuration
files. After removing a frontend & its config file(s), you'd just re-build
the driver data file.