X-Git-Url: http://git.sourceforge.jp/view?a=blobdiff_plain;f=gcc%2Fdoc%2Fmakefile.texi;h=8e76fea57c1245d53a147bda664d0c7dfe43295e;hb=24b8d17fa1980701e479c8e7accd3180fc679735;hp=8dcf4969ae0708e0d890e0f274fc0af475033adc;hpb=26526d23eb2fb904bb83b72cc6ced380ec06c359;p=pf3gnuchains%2Fgcc-fork.git

diff --git a/gcc/doc/makefile.texi b/gcc/doc/makefile.texi
index 8dcf4969ae0..8e76fea57c1 100644
--- a/gcc/doc/makefile.texi
+++ b/gcc/doc/makefile.texi
@@ -1,4 +1,5 @@
-@c Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+@c Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008, 2010
+@c Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
@@ -21,6 +22,9 @@ 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.
 
@@ -42,12 +46,11 @@ 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.
+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}.
+Generates files in the source directory that are not version-controlled but
+should go into a release tarball.
 
 @item srcinfo
 @itemx srcman
@@ -55,16 +58,16 @@ Copies the info-formatted and manpage documentation into the source
 directory usually for the purpose of generating a release tarball.
 
 @item install
-Installs gcc.
+Installs GCC.
 
 @item uninstall
-Deletes installed files.
+Deletes installed files, though this is not supported.
 
 @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
+You can specify specific tests by setting @env{RUNTESTFLAGS} to be the name
 of the @file{.exp} file, optionally followed by (for some tests) an equals
 and a file wildcard, like:
 
@@ -73,7 +76,7 @@ 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.
+installed, such as Tcl or DejaGnu.
 @end table
 
 The toplevel tree from which you start GCC compilation is not
@@ -97,11 +100,11 @@ 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
+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}.}.
+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:
 
@@ -117,11 +120,11 @@ 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)
+@item stage@var{N}-bubble (@var{N} = 1@dots{}4, profile, feedback)
 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)
+@item all-stage@var{N} (@var{N} = 1@dots{}4, profile, feedback)
 Assuming that stage @var{N} has already been built, rebuild it with the
 appropriate flags.  This is rarely needed.
 
@@ -134,22 +137,23 @@ 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
+Builds a compiler with profiling feedback information.  In this case,
+the second and third stages are named @samp{profile} and @samp{feedback},
+respectively.  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)
+@item stage@var{N}-start (@var{N} = 1@dots{}4, profile, feedback)
 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.}.
+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
+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