diff options
author | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
---|---|---|
committer | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
commit | 554fd8c5195424bdbcabf5de30fdc183aba391bd (patch) | |
tree | 976dc5ab7fddf506dadce60ae936f43f58787092 /gcc/doc/makefile.texi | |
download | cbb-gcc-4.6.4-15d2061ac0796199866debe9ac87130894b0cdd3.tar.bz2 cbb-gcc-4.6.4-15d2061ac0796199866debe9ac87130894b0cdd3.tar.xz |
obtained gcc-4.6.4.tar.bz2 from upstream website;upstream
verified gcc-4.6.4.tar.bz2.sig;
imported gcc-4.6.4 source tree from verified upstream tarball.
downloading a git-generated archive based on the 'upstream' tag
should provide you with a source tree that is binary identical
to the one extracted from the above tarball.
if you have obtained the source via the command 'git clone',
however, do note that line-endings of files in your working
directory might differ from line-endings of the respective
files in the upstream repository.
Diffstat (limited to 'gcc/doc/makefile.texi')
-rw-r--r-- | gcc/doc/makefile.texi | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/gcc/doc/makefile.texi b/gcc/doc/makefile.texi new file mode 100644 index 000000000..8e76fea57 --- /dev/null +++ b/gcc/doc/makefile.texi @@ -0,0 +1,193 @@ +@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. + +@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 are not version-controlled but +should go into a release tarball. + +@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, 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 @env{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, 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, profile, feedback) +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. 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, 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.}. + +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. + |