This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

egcs fixinc: This Time For Sure (tm)

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

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.


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>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]