193 lines
7.0 KiB
Plaintext
193 lines
7.0 KiB
Plaintext
@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.
|
|
|