8sa1-gcc/gcc/fixinc
Bruce Korb 7db774d2f1 1. the file name lists ought to be restricted to "*.h" anyway 2. C++ files may be named .../[a-z]++/...
1.  the file name lists ought to be restricted to "*.h" anyway
2.  C++ files may be named .../[a-z]++/... also
3.  the original egrep pattern was not finding "__MIPSEL".
    I am not enough of a regexp person to know why.
4.  Adding copyright year and attribution to output
5.  Add copyright date and attribution
6.  Clarify a bunch of comments
7.  Remove dead template text
8.  Correct the counting of regular expressions

From-SVN: r26363
1999-04-12 07:11:20 +00:00
..
fixinc.dgux
fixinc.interix Forgot to check in. 1999-04-11 05:35:44 -06:00
fixinc.irix
fixinc.ptx
fixinc.sco
fixinc.svr4
fixinc.winnt
fixinc.wrap
fixinc.x86-linux-gnu
fixincl.c Reworked method for traversing sym-linked directory hierarchies 1999-03-31 11:51:29 +00:00
fixincl.sh hackshell.tpl: Skip links to directories, to avoid removing them. 1999-04-03 16:36:22 -07:00
fixincl.tpl 1. the file name lists ought to be restricted to "*.h" anyway 2. C++ files may be named .../[a-z]++/... 1999-04-12 07:11:20 +00:00
fixincl.x hackshell.tpl: Skip links to directories, to avoid removing them. 1999-04-03 16:36:22 -07:00
genfixes Ensure that the server shell is _NOT_ csh 1999-04-05 06:58:30 +00:00
hackshell.tpl hackshell.tpl: Skip links to directories, to avoid removing them. 1999-04-03 16:36:22 -07:00
inclhack.def 1. the file name lists ought to be restricted to "*.h" anyway 2. C++ files may be named .../[a-z]++/... 1999-04-12 07:11:20 +00:00
inclhack.sh hackshell.tpl: Skip links to directories, to avoid removing them. 1999-04-03 16:36:22 -07:00
inclhack.tpl 1. the file name lists ought to be restricted to "*.h" anyway 2. C++ files may be named .../[a-z]++/... 1999-04-12 07:11:20 +00:00
Makefile.in
mkfixinc.sh UNTESTED support for interix 1999-04-02 10:50:42 +00:00
procopen.c
README Made more current 1999-03-29 08:22:24 +00:00
regex.c
regex.h
server.c
server.h

The fast-fixincludes system now, to the best of our collective belief,
correctly implements exactly the same functionality as the previous
fixincludes and fixinc.* shell scripts.  On systems where many fixes
are required, this is accomplished by putting most of the
functionality into a binary executable.  On systems that had dedicated
fixinc.* shell scripts, those scripts are still used by default until
they can be converted.

POSSIBLE PROBLEMS

There may be some systems on which the fixinc binary program appears
to be functional, but fails to work.  Current thinking is that this
is due to some new process limitations (fork() calls) on those
systems.  If you are experiencing this problem, then copy the script
${src}/gcc/fixinc/inclhack.sh into ${builddir}/gcc/fixinc.sh and run
make again.

And, *please* also report the problem with a description of
the failure mode (symptoms) and the output from:

        egcs/config.guess

to me:  Bruce Korb <fixincludes@autogen.freeservers.com>

TO DO

* fixincl needs to be converted to use gcc's system.h, libiberty, and
  other portability frameworks.


THEORY OF OPERATION

See also:  http://autogen.freeservers.com

The set of fixes required was distilled down to just the data required
to specify what needed to happen for each fix.  Those data were edited
into a new file named gcc/fixinc/inclhack.def.  A program called
AutoGen (http://autogen.freeservers.com) uses these definitions to
instantiate several different templates (gcc/fixinc/*.tpl) that then
produces a fixincludes replacement shell script (inclhack.sh), a
replacement binary program (fixincl.x) and a script to drive the
binary fixincl.sh).

If there is no special purpose script, then mkfixinc.sh will try to
compile, link and test execute the binary version.  If it cannot be
successfully built, the shell version will be used instead.  If
mkfixinc.sh determines that your system needs machine-specific fixes
that have not yet been applied to inclhack.def, it will install and
use the current fixinc.* for that system instead.

Usually, the mkfixinc.sh script will be able to detect when
the binary is not runable.  If you do have problems, however,
please see "POSSIBLE PROBLEMS" above.  Thank you.

Regards,
	Bruce <fixincludes@autogen.freeservers.com>
	Robert <RobertLipe@usa.net>
	Manfred <manfred@s-direktnet.de>