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