1 files changed, 192 insertions, 0 deletions
diff --git a/gcc-4.2.1-5666.3/gcc/doc/makefile.texi b/gcc-4.2.1-5666.3/gcc/doc/makefile.texi
new file mode 100644
index 000000000..f4513b79d
--- /dev/null
+++ b/gcc-4.2.1-5666.3/gcc/doc/makefile.texi
@@ -0,0 +1,192 @@
+@c Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+@c This is part of the GCC manual.
+@c For copying conditions, see the file gcc.texi.
+
+@node Makefile
+@subsection Makefile Targets
+@cindex makefile targets
+@cindex targets, makefile
+
+These targets are available from the @samp{gcc} directory:
+
+@table @code
+@item all
+This is the default target.  Depending on what your build/host/target
+configuration is, it coordinates all the things that need to be built.
+
+@item doc
+Produce info-formatted documentation and man pages.  Essentially it
+calls @samp{make man} and @samp{make info}.
+
+@item dvi
+Produce DVI-formatted documentation.
+
+@item pdf
+Produce PDF-formatted documentation.
+
+@item html
+Produce HTML-formatted documentation.
+
+@item man
+Generate man pages.
+
+@item info
+Generate info-formatted pages.
+
+@item mostlyclean
+Delete the files made while building the compiler.
+
+@item clean
+That, and all the other files built by @samp{make all}.
+
+@item distclean
+That, and all the files created by @command{configure}.
+
+@item maintainer-clean
+Distclean plus any file that can be generated from other files.  Note
+that additional tools may be required beyond what is normally needed to
+build gcc.
+
+@item srcextra
+Generates files in the source directory that do not exist in CVS but
+should go into a release tarball.  One example is @file{gcc/java/parse.c}
+which is generated from the CVS source file @file{gcc/java/parse.y}.
+
+@item srcinfo
+@itemx srcman
+Copies the info-formatted and manpage documentation into the source
+directory usually for the purpose of generating a release tarball.
+
+@item install
+Installs gcc.
+
+@item uninstall
+Deletes installed files.
+
+@item check
+Run the testsuite.  This creates a @file{testsuite} subdirectory that
+has various @file{.sum} and @file{.log} files containing the results of
+the testing.  You can run subsets with, for example, @samp{make check-gcc}.
+You can specify specific tests by setting RUNTESTFLAGS to be the name
+of the @file{.exp} file, optionally followed by (for some tests) an equals
+and a file wildcard, like:
+
+@smallexample
+make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
+@end smallexample
+
+Note that running the testsuite may require additional tools be
+installed, such as TCL or dejagnu.
+@end table
+
+The toplevel tree from which you start GCC compilation is not
+the GCC directory, but rather a complex Makefile that coordinates
+the various steps of the build, including bootstrapping the compiler
+and using the new compiler to build target libraries.
+
+When GCC is configured for a native configuration, the default action
+for @command{make} is to do a full three-stage bootstrap.  This means
+that GCC is built three times---once with the native compiler, once with
+the native-built compiler it just built, and once with the compiler it
+built the second time.  In theory, the last two should produce the same
+results, which @samp{make compare} can check.  Each stage is configured
+separately and compiled into a separate directory, to minimize problems
+due to ABI incompatibilities between the native compiler and GCC.
+
+If you do a change, rebuilding will also start from the first stage
+and ``bubble'' up the change through the three stages.  Each stage
+is taken from its build directory (if it had been built previously),
+rebuilt, and copied to its subdirectory.  This will allow you to, for
+example, continue a bootstrap after fixing a bug which causes the
+stage2 build to crash.  It does not provide as good coverage of the
+compiler as bootstrapping from scratch, but it ensures that the new
+code is syntactically correct (e.g. that you did not use GCC extensions
+by mistake), and avoids spurious bootstrap comparison
+failures@footnote{Except if the compiler was buggy and miscompiled
+  some of the files that were not modified.  In this case, it's best
+  to use @command{make restrap}.}.
+
+Other targets available from the top level include:
+
+@table @code
+@item bootstrap-lean
+Like @code{bootstrap}, except that the various stages are removed once
+they're no longer needed.  This saves disk space.
+
+@item bootstrap2
+@itemx bootstrap2-lean
+Performs only the first two stages of bootstrap.  Unlike a three-stage
+bootstrap, this does not perform a comparison to test that the compiler
+is running properly.  Note that the disk space required by a ``lean''
+bootstrap is approximately independent of the number of stages.
+
+@item stage@var{N}-bubble (@var{N} = 1@dots{}4)
+Rebuild all the stages up to @var{N}, with the appropriate flags,
+``bubbling'' the changes as described above.
+
+@item all-stage@var{N} (@var{N} = 1@dots{}4)
+Assuming that stage @var{N} has already been built, rebuild it with the
+appropriate flags.  This is rarely needed.
+
+@item cleanstrap
+Remove everything (@samp{make clean}) and rebuilds (@samp{make bootstrap}).
+
+@item compare
+Compares the results of stages 2 and 3.  This ensures that the compiler
+is running properly, since it should produce the same object files
+regardless of how it itself was compiled.
+
+@item profiledbootstrap
+Builds a compiler with profiling feedback information.  For more
+information, see
+@ref{Building,,Building with profile feedback,gccinstall,Installing GCC}.
+
+@item restrap
+Restart a bootstrap, so that everything that was not built with
+the system compiler is rebuilt.
+
+@item stage@var{N}-start (@var{N} = 1@dots{}4)
+For each package that is bootstrapped, rename directories so that,
+for example, @file{gcc} points to the stage@var{N} GCC, compiled
+with the stage@var{N-1} GCC@footnote{Customarily, the system compiler
+  is also termed the @file{stage0} GCC.}.
+
+You will invoke this target if you need to test or debug the
+stage@var{N} GCC.  If you only need to execute GCC (but you need
+not run @samp{make} either to rebuild it or to run test suites),
+you should be able to work directly in the @file{stage@var{N}-gcc}
+directory.  This makes it easier to debug multiple stages in
+parallel.
+
+@item stage
+For each package that is bootstrapped, relocate its build directory
+to indicate its stage.  For example, if the @file{gcc} directory
+points to the stage2 GCC, after invoking this target it will be
+renamed to @file{stage2-gcc}.
+
+@end table
+
+If you wish to use non-default GCC flags when compiling the stage2 and
+stage3 compilers, set @code{BOOT_CFLAGS} on the command line when doing
+@samp{make}.
+
+Usually, the first stage only builds the languages that the compiler
+is written in: typically, C and maybe Ada.  If you are debugging a
+miscompilation of a different stage2 front-end (for example, of the
+Fortran front-end), you may want to have front-ends for other languages
+in the first stage as well.  To do so, set @code{STAGE1_LANGUAGES}
+on the command line when doing @samp{make}.
+
+For example, in the aforementioned scenario of debugging a Fortran
+front-end miscompilation caused by the stage1 compiler, you may need a
+command like
+
+@example
+make stage2-bubble STAGE1_LANGUAGES=c,fortran
+@end example
+
+Alternatively, you can use per-language targets to build and test
+languages that are not enabled by default in stage1.  For example,
+@command{make f951} will build a Fortran compiler even in the stage1
+build directory.
+