This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
egcs fixinc: This Time For Sure (tm)
- To: EGCS-ers <egcs at cygnus dot com>
- Subject: egcs fixinc: This Time For Sure (tm)
- From: Bruce Korb <korbb at datadesign dot com>
- Date: Wed, 04 Mar 1998 14:39:24 -0800
- Organization: Data Design Systems, Inc.
Hi EGCS-ers,
Once upon a time, a long, long time ago (August/September
1997) I exchanged some mail about include hackery. The issue
has never died, tho it was dormant while Jeff got egcs 1.0 and
1.... released. Well, I am trying to dust it off again. The
current state of the discussion and progress is this, randomly
ordered:
1. The new script is faster than the old by taking advantage
of file content caching (saves about 10%)
2. It is easier to maintain because the essence of each 'fix'
is boiled down into a description that contains:
a. a fix name
b. a list of files it applies to
c. a regular expression that must be found in the file
d. a regular expression that must not be found
e. a shell test expression that must yield true
and one of:
f. a list of sed expressions to apply the fix
g. a shell script that applies the fix
To this, I intend to add:
h. a list of match expressions that are matched against
the output of the "config.guess" script
i. an indicator that says whether the fix applies if
any of the expressions match, or if it applies
only if none of the expressions match.
b, c, d, e and h are all optional and multiple may apply.
3. It is easier to enhance because once any enhancement is
successfully worked out, it can immediately be applied to
all the fixes correctly. (It is a mechanical application.)
4. There now exists a C program that produces the identical
results to the shell script that runs in about 1/3 the time.
Any changes to the fix descriptions are immediately implemented
in both the shell script and the program.
5. I am not an expert at writing code that compiles and runs on
the world of platforms. Therefore, I must look for volunteers
to try out the program on many platforms before it can be
jumped on.
Underpinning all of this is a code generation toy I have put
together over the years. The proposal on the floor is to put
this engine and my new method of fixing includes into an "EGCS
scratch" area that proactively defensive (i.e. adventurous)
people can optionally configure into their builds.
The files will be CVS checkout-able in an egcs temporary
subdirectory (e.g. contrib/fixinc). It will be activated
via a magic enable option to configure (e.g. --enable-fast-fixinc).
that will invoke the new fixincludes stuff in preference
to the current scripts. To be able to actually modify these
new scripts, you will need the 'autogen' code generation toy.
It should be made available in contrib/autogen, or some such.
A Cygnus person will fill in the precise location information.
Before you can build autogen, tho, you will need egcs or some
other ANSI-compliant compiler. K&R will not do. The generated
fixincludes files are all clearly marked, "DO NOT EDIT THIS FILE".
Eventually, when it becomes clear that this new script and
program work on the currently known world, then the new script
will become the new default fixincludes and the program will
become the adventurous option. Or, if uncertainties and
anxieties can be allayed, then we may jump directly to the
C program. Which is done will depend on warm, fuzzy feelings
that are based on feedback from our "proactively defensive
EGCS-ers". You.
HOW YOU CAN HELP
First, speak now about your anxieties so we can see a few
potholes before we hit them. Wait for the announcement that
the new sources have been installed.
Then, down load the latest stuff from the egcs repository
and configure your compiler with --enable-fast-fixinc.
Then, let me know if anything goes wrong!!
Be sure to include "fixincl" in your subject line.
mailto: Bruce Korb <ddsinc09 at ix.netcom.com>