0
|
1 @c Copyright (C) 2001, 2002, 2003, 2004, 2006, 2008
|
|
2 @c Free Software Foundation, Inc.
|
|
3 @c This is part of the GCC manual.
|
|
4 @c For copying conditions, see the file gcc.texi.
|
|
5
|
|
6 @node Makefile
|
|
7 @subsection Makefile Targets
|
|
8 @cindex makefile targets
|
|
9 @cindex targets, makefile
|
|
10
|
|
11 These targets are available from the @samp{gcc} directory:
|
|
12
|
|
13 @table @code
|
|
14 @item all
|
|
15 This is the default target. Depending on what your build/host/target
|
|
16 configuration is, it coordinates all the things that need to be built.
|
|
17
|
|
18 @item doc
|
|
19 Produce info-formatted documentation and man pages. Essentially it
|
|
20 calls @samp{make man} and @samp{make info}.
|
|
21
|
|
22 @item dvi
|
|
23 Produce DVI-formatted documentation.
|
|
24
|
|
25 @item pdf
|
|
26 Produce PDF-formatted documentation.
|
|
27
|
|
28 @item html
|
|
29 Produce HTML-formatted documentation.
|
|
30
|
|
31 @item man
|
|
32 Generate man pages.
|
|
33
|
|
34 @item info
|
|
35 Generate info-formatted pages.
|
|
36
|
|
37 @item mostlyclean
|
|
38 Delete the files made while building the compiler.
|
|
39
|
|
40 @item clean
|
|
41 That, and all the other files built by @samp{make all}.
|
|
42
|
|
43 @item distclean
|
|
44 That, and all the files created by @command{configure}.
|
|
45
|
|
46 @item maintainer-clean
|
|
47 Distclean plus any file that can be generated from other files. Note
|
|
48 that additional tools may be required beyond what is normally needed to
|
|
49 build gcc.
|
|
50
|
|
51 @item srcextra
|
|
52 Generates files in the source directory that do not exist in CVS but
|
|
53 should go into a release tarball. One example is @file{gcc/java/parse.c}
|
|
54 which is generated from the CVS source file @file{gcc/java/parse.y}.
|
|
55
|
|
56 @item srcinfo
|
|
57 @itemx srcman
|
|
58 Copies the info-formatted and manpage documentation into the source
|
|
59 directory usually for the purpose of generating a release tarball.
|
|
60
|
|
61 @item install
|
|
62 Installs gcc.
|
|
63
|
|
64 @item uninstall
|
|
65 Deletes installed files.
|
|
66
|
|
67 @item check
|
|
68 Run the testsuite. This creates a @file{testsuite} subdirectory that
|
|
69 has various @file{.sum} and @file{.log} files containing the results of
|
|
70 the testing. You can run subsets with, for example, @samp{make check-gcc}.
|
|
71 You can specify specific tests by setting RUNTESTFLAGS to be the name
|
|
72 of the @file{.exp} file, optionally followed by (for some tests) an equals
|
|
73 and a file wildcard, like:
|
|
74
|
|
75 @smallexample
|
|
76 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
|
|
77 @end smallexample
|
|
78
|
|
79 Note that running the testsuite may require additional tools be
|
|
80 installed, such as TCL or dejagnu.
|
|
81 @end table
|
|
82
|
|
83 The toplevel tree from which you start GCC compilation is not
|
|
84 the GCC directory, but rather a complex Makefile that coordinates
|
|
85 the various steps of the build, including bootstrapping the compiler
|
|
86 and using the new compiler to build target libraries.
|
|
87
|
|
88 When GCC is configured for a native configuration, the default action
|
|
89 for @command{make} is to do a full three-stage bootstrap. This means
|
|
90 that GCC is built three times---once with the native compiler, once with
|
|
91 the native-built compiler it just built, and once with the compiler it
|
|
92 built the second time. In theory, the last two should produce the same
|
|
93 results, which @samp{make compare} can check. Each stage is configured
|
|
94 separately and compiled into a separate directory, to minimize problems
|
|
95 due to ABI incompatibilities between the native compiler and GCC.
|
|
96
|
|
97 If you do a change, rebuilding will also start from the first stage
|
|
98 and ``bubble'' up the change through the three stages. Each stage
|
|
99 is taken from its build directory (if it had been built previously),
|
|
100 rebuilt, and copied to its subdirectory. This will allow you to, for
|
|
101 example, continue a bootstrap after fixing a bug which causes the
|
|
102 stage2 build to crash. It does not provide as good coverage of the
|
|
103 compiler as bootstrapping from scratch, but it ensures that the new
|
|
104 code is syntactically correct (e.g., that you did not use GCC extensions
|
|
105 by mistake), and avoids spurious bootstrap comparison
|
|
106 failures@footnote{Except if the compiler was buggy and miscompiled
|
|
107 some of the files that were not modified. In this case, it's best
|
|
108 to use @command{make restrap}.}.
|
|
109
|
|
110 Other targets available from the top level include:
|
|
111
|
|
112 @table @code
|
|
113 @item bootstrap-lean
|
|
114 Like @code{bootstrap}, except that the various stages are removed once
|
|
115 they're no longer needed. This saves disk space.
|
|
116
|
|
117 @item bootstrap2
|
|
118 @itemx bootstrap2-lean
|
|
119 Performs only the first two stages of bootstrap. Unlike a three-stage
|
|
120 bootstrap, this does not perform a comparison to test that the compiler
|
|
121 is running properly. Note that the disk space required by a ``lean''
|
|
122 bootstrap is approximately independent of the number of stages.
|
|
123
|
|
124 @item stage@var{N}-bubble (@var{N} = 1@dots{}4)
|
|
125 Rebuild all the stages up to @var{N}, with the appropriate flags,
|
|
126 ``bubbling'' the changes as described above.
|
|
127
|
|
128 @item all-stage@var{N} (@var{N} = 1@dots{}4)
|
|
129 Assuming that stage @var{N} has already been built, rebuild it with the
|
|
130 appropriate flags. This is rarely needed.
|
|
131
|
|
132 @item cleanstrap
|
|
133 Remove everything (@samp{make clean}) and rebuilds (@samp{make bootstrap}).
|
|
134
|
|
135 @item compare
|
|
136 Compares the results of stages 2 and 3. This ensures that the compiler
|
|
137 is running properly, since it should produce the same object files
|
|
138 regardless of how it itself was compiled.
|
|
139
|
|
140 @item profiledbootstrap
|
|
141 Builds a compiler with profiling feedback information. For more
|
|
142 information, see
|
|
143 @ref{Building,,Building with profile feedback,gccinstall,Installing GCC}.
|
|
144
|
|
145 @item restrap
|
|
146 Restart a bootstrap, so that everything that was not built with
|
|
147 the system compiler is rebuilt.
|
|
148
|
|
149 @item stage@var{N}-start (@var{N} = 1@dots{}4)
|
|
150 For each package that is bootstrapped, rename directories so that,
|
|
151 for example, @file{gcc} points to the stage@var{N} GCC, compiled
|
|
152 with the stage@var{N-1} GCC@footnote{Customarily, the system compiler
|
|
153 is also termed the @file{stage0} GCC.}.
|
|
154
|
|
155 You will invoke this target if you need to test or debug the
|
|
156 stage@var{N} GCC@. If you only need to execute GCC (but you need
|
|
157 not run @samp{make} either to rebuild it or to run test suites),
|
|
158 you should be able to work directly in the @file{stage@var{N}-gcc}
|
|
159 directory. This makes it easier to debug multiple stages in
|
|
160 parallel.
|
|
161
|
|
162 @item stage
|
|
163 For each package that is bootstrapped, relocate its build directory
|
|
164 to indicate its stage. For example, if the @file{gcc} directory
|
|
165 points to the stage2 GCC, after invoking this target it will be
|
|
166 renamed to @file{stage2-gcc}.
|
|
167
|
|
168 @end table
|
|
169
|
|
170 If you wish to use non-default GCC flags when compiling the stage2 and
|
|
171 stage3 compilers, set @code{BOOT_CFLAGS} on the command line when doing
|
|
172 @samp{make}.
|
|
173
|
|
174 Usually, the first stage only builds the languages that the compiler
|
|
175 is written in: typically, C and maybe Ada. If you are debugging a
|
|
176 miscompilation of a different stage2 front-end (for example, of the
|
|
177 Fortran front-end), you may want to have front-ends for other languages
|
|
178 in the first stage as well. To do so, set @code{STAGE1_LANGUAGES}
|
|
179 on the command line when doing @samp{make}.
|
|
180
|
|
181 For example, in the aforementioned scenario of debugging a Fortran
|
|
182 front-end miscompilation caused by the stage1 compiler, you may need a
|
|
183 command like
|
|
184
|
|
185 @example
|
|
186 make stage2-bubble STAGE1_LANGUAGES=c,fortran
|
|
187 @end example
|
|
188
|
|
189 Alternatively, you can use per-language targets to build and test
|
|
190 languages that are not enabled by default in stage1. For example,
|
|
191 @command{make f951} will build a Fortran compiler even in the stage1
|
|
192 build directory.
|
|
193
|