Commit | Line | Data |
---|---|---|
7d283cc1 RP |
1 | \input texinfo @c -*-para-*- |
2 | @c %**start of header | |
3 | @setfilename cfg-paper.info | |
4 | @settitle On Configuring Development Tools | |
5 | @c %**end of header | |
6 | @setchapternewpage off | |
7 | ||
8 | @titlepage | |
9 | @sp 10 | |
10 | @title{On Configuring Development Tools} | |
11 | @author{K. Richard Pixley} | |
12 | @author{Cygnus Support} | |
13 | @vskip 0pt plus 1filll | |
14 | Copyright @copyright{} 1991 Cygnus Support | |
15 | @end titlepage | |
16 | ||
17 | @ifinfo | |
18 | This document attempts to describe the general concepts behind | |
19 | configuration of the Cygnus Support release of the @sc{gnu} Development | |
20 | Tools. It also discusses common usage.. | |
21 | ||
22 | Copyright @copyright{} 1991 Cygnus Support | |
23 | @end ifinfo | |
24 | ||
25 | @node top, Some Basic Terms, (dir), (dir) | |
26 | ||
27 | @ifinfo | |
28 | This document attempts to describe the general concepts behind | |
29 | configuration of the Cygnus Support release of the @sc{gnu} Development | |
30 | Tools. It also discusses common usage. | |
31 | @end ifinfo | |
32 | ||
33 | @menu | |
34 | * Some Basic Terms:: Some Basic Terms | |
35 | * Specifics.:: Specifics | |
36 | * Building Development Environments:: Building Development Environments | |
37 | * A Walk Through:: A Walk Through | |
38 | * Final Notes:: Final Notes | |
39 | * Index:: Index | |
40 | @end menu | |
41 | ||
42 | @node Some Basic Terms, Specifics., top, top | |
43 | @chapter Some Basic Terms | |
44 | ||
45 | There are a lot of terms that are frequently used when discussing | |
46 | development tools. Most of the common terms have been used for many | |
47 | different concepts such that their meanings have become ambiguous to the | |
48 | point of being confusing. Typically, we only guess at their meanings | |
49 | from context and we frequently guess wrong. | |
50 | ||
51 | This document uses very few terms by comparison. The intent is to make | |
52 | the concepts as clear as possible in order to convey the usage and | |
53 | intent of these tools. | |
54 | ||
55 | @emph{Programs} run on @emph{machines}. Programs are very nearly always | |
56 | written in @emph{source}. Programs are @emph{built} from source. | |
57 | @emph{Compilation} is a process that is frequently, but not always, used | |
58 | when building programs. | |
59 | @cindex Programs | |
60 | @cindex Machines | |
61 | @cindex Source | |
62 | @cindex Building | |
63 | @cindex Compilation | |
64 | ||
65 | @menu | |
66 | * Host Environments:: Host Environments | |
67 | * Configuration Time Options:: Configuration Time Options | |
68 | @end menu | |
69 | ||
70 | @node Host Environments, Configuration Time Options, Some Basic Terms, Some Basic Terms | |
71 | @section Host Environments | |
72 | ||
73 | @cindex host | |
74 | In this document, the word @emph{host} refers to the environment in | |
75 | which the source in question will be compiled. @emph{host} and | |
76 | @emph{host name} have nothing to do with the proper name of your host, | |
77 | like @emph{ucbvax}, @emph{prep.ai.mit.edu} or @emph{att.com}. Instead | |
78 | they refer to things like @emph{sun4} and @emph{dec3100}. | |
79 | ||
80 | Forget for a moment that this particular directory of source is the | |
81 | source for a development environment. Instead, pretend that it is the | |
82 | source for a simpler, more mundane, application, say, a desk calculator. | |
83 | ||
84 | Source that can be compiled in more than one environment, generally | |
85 | needs to be set up for each environment explicitly. Here we refer to | |
86 | that process as configuration. That is, we configure the source for a | |
87 | host. | |
88 | ||
89 | For example, if we wanted to configure our mythical desk calculator to | |
90 | compile on a SparcStation, we might configure for host sun4. With our | |
91 | configuration system: | |
92 | ||
93 | @example | |
94 | cd desk-calculator ; ./configure sun4 | |
95 | @end example | |
96 | ||
97 | @noindent | |
98 | does the trick. @code{configure} is a shell script that sets up Makefiles, | |
99 | subdirectories, and symbolic links appropriate for compiling the source | |
100 | on a sun4. | |
101 | ||
102 | The @emph{host} environment does not necessarily refer to the machine on | |
103 | which the tools are built. It is possible to provide a sun3 development | |
104 | environment on a sun4. If we wanted to use a cross compiler on the sun4 | |
105 | to build a program intended to be run on a sun3, we would configure the | |
106 | source for sun3. | |
107 | ||
108 | @example | |
109 | cd desk-calculator ; ./configure sun3 | |
110 | @end example | |
111 | ||
112 | @noindent | |
113 | The fact that we are actually building the program on a sun4 makes no | |
114 | difference if the sun3 cross compiler presents an environment that looks | |
115 | like a sun3 from the point of view of the desk calculator source code. | |
116 | Specifically, the environment is a sun3 environment if the header files, | |
117 | predefined symbols, and libraries appear as they do on a sun3. | |
118 | ||
119 | Nor does the host environment refer to the the machine on which the | |
120 | program to be built will run. It is possible to provide a sun3 | |
121 | emulation environment on a sun4 such that programs built in a sun3 | |
122 | development environment actually run on the sun4. This technique is | |
123 | often used within individual programs to remedy deficiencies in the host | |
124 | operating system. For example, some operating systems do not provide | |
125 | the @code{bcopy()} function and so it is emulated using the | |
126 | @code{memset()} funtion. | |
127 | ||
128 | Host environment simply refers to the environment in which the program | |
129 | will be built from the source. | |
130 | ||
131 | ||
132 | @node Configuration Time Options, , Host Environments, Some Basic Terms | |
133 | @section Configuration Time Options | |
134 | ||
135 | Many programs have compile time options. That is, features of the | |
136 | program that are either compiled into the program or not based on a | |
137 | choice made by the person who builds the program. We refer to these as | |
138 | @emph{configuration options}. For example, our desk calculator might be | |
139 | capable of being compiled into a program that either uses infix notation | |
140 | or postfix as a configuration option. For a sun3, to choose infix you | |
141 | might use: | |
142 | ||
143 | @example | |
144 | ./configure sun3 -notation=infix | |
145 | @end example | |
146 | ||
147 | @noindent | |
148 | while for a sun4 with postfix you might use: | |
149 | ||
150 | @example | |
151 | ./configure sun4 -notation=postfix | |
152 | @end example | |
153 | ||
154 | If we wanted to build both at the same time, in the same directory | |
155 | structure, the intermediate pieces used in the build process must be | |
156 | kept separate. | |
157 | ||
158 | @example | |
159 | ./configure sun4 -subdirs -notation=postfix | |
160 | ./configure sun3 -subdirs -notation=infix | |
161 | @end example | |
162 | ||
163 | @noindent | |
164 | will create subdirectories for the intermediate pieces of the sun4 and | |
165 | sun3 configurations. This is necessary as previous systems were only | |
166 | capable of one configuration at a time. Otherwise, a second | |
167 | configuration would write over the first. We've chosen to retain this | |
168 | behaviour so the @code{-subdirs} configuration option is necessary to | |
169 | get the new behaviour. The order of the arguments doesn't matter. | |
170 | There should be exactly one argument without a leading '@minus{}' sign | |
171 | and that argument will be assumed to be the host name. | |
172 | ||
173 | From here on the examples will assume that you want to build the tools | |
174 | @emph{in place} and won't show the @code{-subdirs} option, but remember | |
175 | that it is available. | |
176 | ||
177 | In order to actually install the program, the configuration system needs | |
178 | to know where you would like the program installed. The default | |
179 | location is @file{/usr/local}. We refer to this location as | |
180 | @code{$(prefix)}. All user visible programs will be installed in | |
181 | @file{@code{$(prefix)}/bin}. All other programs and files will be | |
182 | installed in a subdirectory of @file{@code{$(prefix)}/lib}. | |
183 | ||
184 | NOTE: @code{$(prefix)} was previously known as @code{$(destdir)}. | |
185 | ||
186 | You can elect to change @code{$(prefix)} only as a configuration time | |
187 | option. | |
188 | ||
189 | @example | |
190 | ./configure sun4 -notation=postfix -prefix=/local | |
191 | @end example | |
192 | ||
193 | @noindent | |
194 | Will configure the source such that: | |
195 | ||
196 | @example | |
197 | make install | |
198 | @end example | |
199 | ||
200 | @noindent | |
201 | will put it's programs in @file{/local/bin} and @file{/local/lib/gcc}. | |
202 | If you change @code{$(prefix)} after building the source, you will need | |
203 | to: | |
204 | ||
205 | @example | |
206 | make clean | |
207 | @end example | |
208 | ||
209 | @noindent | |
210 | before the change will be propogated properly. This is because some | |
211 | tools need to know the locations of other tools. | |
212 | ||
213 | With these concepts in mind, we can drop the desk calculator example and | |
214 | move on to the application that resides in these directories, namely, | |
215 | the source to a development environment. | |
216 | ||
217 | @node Specifics., Building Development Environments, Some Basic Terms, top | |
218 | @chapter Specifics | |
219 | ||
220 | The @sc{gnu} Development Tools can be built on a wide variety of hosts. So, | |
221 | of course, they must be configured. Like the last example, | |
222 | ||
223 | @example | |
224 | ./configure sun4 -prefix=/local | |
225 | ./configure sun3 -prefix=/local | |
226 | @end example | |
227 | ||
228 | @noindent | |
229 | will configure the source to be built in subdirectories, in order to | |
230 | keep the intermediate pieces separate, and to be installed in | |
231 | @file{/local}. | |
232 | ||
233 | When built with suitable development environments, these will be native | |
234 | tools. We'll explain the term @emph{native} later. | |
235 | ||
236 | @node Building Development Environments, A Walk Through, Specifics., top | |
237 | @chapter Building Development Environments | |
238 | ||
239 | @cindex Target | |
240 | ||
241 | The Cygnus Support @sc{gnu} development tools can not only be built in a | |
242 | number of host development environments, they can also be configured to | |
243 | create a number of different development environments on each of those | |
244 | hosts. We refer to a specific development environment created as a | |
245 | @emph{target}. That is, the word @emph{target} refers to the development | |
246 | environment produced by compiling this source and installing the | |
247 | resulting programs. | |
248 | ||
249 | For the Cygnus Support @sc{gnu} development tools, the default target is the | |
250 | same as the host. That is, the development environment produced is | |
251 | intended to be compatible with the environment used to build the tools. | |
252 | ||
253 | In the example above, we created two configurations, one for sun4 and | |
254 | one for sun3. The first configuration is expecting to be built in a | |
255 | sun4 development environment, to create a sun4 development environment. | |
256 | It doesn't necessarily need to be built on a sun4 if a sun4 development | |
257 | environment is available elsewhere. Likewise, if the available sun4 | |
258 | development environment produces executables intended for something | |
259 | other than sun4, then the development environment built from this sun4 | |
260 | configuration will run on something other than a sun4. From the point | |
261 | of view of the configuration system and the @sc{gnu} development tools | |
262 | source, this doesn't matter. What matters is that they will be built in | |
263 | a sun4 environment. | |
264 | ||
265 | Similarly, the second configuration given above is expecting to be built | |
266 | in a sun3 development environment, to create a sun3 development | |
267 | environment. | |
268 | ||
269 | The development environment produced, is a configuration time option, | |
270 | just like @code{$(prefix)}. | |
271 | ||
272 | @example | |
273 | ./configure sun4 -prefix=/local -target=sun3 | |
274 | ./configure sun3 -prefix=/local -target=sun4 | |
275 | @end example | |
276 | ||
277 | In this example, like before, we create two configurations. The first | |
278 | is intended to be built in a sun4 environment, in subdirectories, to be | |
279 | installed in @file{/local}. The second is intended to be built in a | |
280 | sun3 environment, in subdirectories, to be installed in @file{/local}. | |
281 | ||
282 | Unlike the previous example, the first configuration will produce a sun3 | |
283 | development environment, perhaps even suitable for building the second | |
284 | configuration. Likewise, the second configuration will produce a sun4 | |
285 | development environment, perhaps even suitable for building the first | |
286 | configuration. | |
287 | ||
288 | The development environment used to build these configurations will | |
289 | determine the machines on which the resulting development environments | |
290 | can be used. | |
291 | ||
292 | ||
293 | @node A Walk Through, Final Notes, Building Development Environments, top | |
294 | @chapter A Walk Through | |
295 | ||
296 | ||
297 | @menu | |
298 | * Native Development Environments:: Native Development Environments | |
299 | * Emulation Environments:: Emulation Environments | |
300 | * Simple Cross Environments:: Simple Cross Environments | |
301 | * Crossing Into Targets:: Crossing Into Targets | |
302 | * The Three Party Cross:: The Three Party Cross | |
303 | @end menu | |
304 | ||
305 | @node Native Development Environments, Emulation Environments, A Walk Through, A Walk Through | |
306 | @section Native Development Environments | |
307 | ||
308 | Let us assume for a moment that you have a sun4 and that with your sun4 | |
309 | you received a development environment. This development environment is | |
310 | intended to be run on your sun4 to build programs that can be run on | |
311 | your sun4. You could, for instance, run this development environment on | |
312 | your sun4 to build our example desk calculator program. You could then | |
313 | run the desk calculator program on your sun4. | |
314 | ||
315 | @cindex Native | |
316 | @cindex Foreign | |
317 | The resulting desk calculator program is referred to as a @emph{native} | |
318 | program. The development environment itself is composed of native | |
319 | programs that, when run, build other native programs. Any other program | |
320 | is referred to as @emph{foreign}. Programs intended for other machines are | |
321 | foreign programs. | |
322 | ||
323 | This type of development environment, which is by far the most common, | |
324 | is refered to as @emph{native}. That is, a native development environment | |
325 | runs on some machine to build programs for that same machine. The | |
326 | process of using a native development environment to build native | |
327 | programs is called a @emph{native} build. | |
328 | ||
329 | @example | |
330 | ./configure sun4 | |
331 | @end example | |
332 | ||
333 | @noindent | |
334 | will configure this source such that when built in a sun4 development | |
335 | environment, with a development environment that builds programs | |
336 | intended to be run on sun4 machines, the programs built will be native | |
337 | programs and the resulting development environment will be a native | |
338 | development environment. | |
339 | ||
340 | The development system that came with your sun4 is one such environment. | |
341 | Using it to build the @sc{gnu} Development Tools is a very common activity | |
342 | and the resulting development environment is quite popular. | |
343 | ||
344 | @example | |
345 | make all | |
346 | @end example | |
347 | ||
348 | @noindent | |
349 | will build the tools as configured and will assume that you want to use | |
350 | the native development environment that came with your machine. | |
351 | ||
352 | @cindex Bootstrapping | |
353 | @cindex Stage1 | |
354 | Using a development environment to build a development environment is | |
355 | called @emph{bootstrapping}. The Cygnus Support release of the @sc{gnu} | |
356 | Development Tools is capable of bootstrapping itself. This is a very | |
357 | powerful feature that we'll return to later. For now, let's pretend | |
358 | that you used the native development environment that came with your | |
359 | sun4 to bootstrap the Cygnus Support release and let's call the new | |
360 | development environment @emph{stage1}. | |
361 | ||
362 | Why bother? Well, most people find that the Cygnus Support release | |
363 | builds programs that run faster and take up less space than the native | |
364 | development environments that came with their machines. Some people | |
365 | didn't get development environments with their machines and some people | |
366 | just like using the @sc{gnu} tools better than using other tools. | |
367 | ||
368 | @cindex Stage2 | |
369 | While you're at it, if the @sc{gnu} tools produce better programs, maybe you | |
370 | should use them to build the @sc{gnu} tools. It's a good idea, so let's | |
371 | pretend that you do. Let's call the new development environment | |
372 | @emph{stage2}. | |
373 | ||
374 | @cindex Stage3 | |
375 | So far you've built a development environment, stage1, and you've used | |
376 | stage1 to build a new, faster and smaller development environment, | |
377 | stage2, but you haven't run any of the programs that the @sc{gnu} tools have | |
378 | built. You really don't yet know if these tools work. Do you have any | |
379 | programs built with the @sc{gnu} tools? Yes, you do. stage2. What does | |
380 | that program do? It builds programs. Ok, do you have any source handy | |
381 | to build into a program? Yes, you do. The @sc{gnu} tools themselves. In | |
382 | fact, if you use stage2 to build the @sc{gnu} tools again the resulting | |
383 | programs should be identical to stage2. Let's pretend that you do and | |
384 | call the new development environment @emph{stage3}. | |
385 | ||
386 | @cindex Three stage boot | |
387 | You've just completed what's called a @emph{three stage boot}. You now have | |
388 | a small, fast, somewhat tested, development environment. | |
389 | ||
390 | @example | |
391 | make bootstrap | |
392 | @end example | |
393 | ||
394 | @noindent | |
395 | will do a three stage boot across all tools and will compare stage2 to | |
396 | stage3 and complain if they are not identical. | |
397 | ||
398 | Once built, | |
399 | ||
400 | @example | |
401 | make install | |
402 | @end example | |
403 | ||
404 | @noindent | |
405 | will install the development environment in the default location or in | |
406 | @code{$(prefix)} if you specified an alternate when you configured. | |
407 | ||
408 | @cindex Cross | |
409 | Any development environment that is not a native development environment | |
410 | is refered to as a @emph{cross} development environment. There are many | |
411 | different types of cross development environments but most fall into one | |
412 | of three basic categories. | |
413 | ||
414 | ||
415 | @node Emulation Environments, Simple Cross Environments, Native Development Environments, A Walk Through | |
416 | @section Emulation Environments | |
417 | ||
418 | @cindex Emulation | |
419 | The first category of cross development environment is called | |
420 | @emph{emulation}. There are two primary types of emulation, but both | |
421 | types result in programs that run on the native host. | |
422 | ||
423 | @cindex Software emulation | |
424 | @cindex Software emulator | |
425 | The first type is @emph{software emulation}. This form of cross | |
426 | development environment involves a native program that when run on the | |
427 | native host, is capable of interpreting, and in most aspects running, a | |
428 | program intended for some other machine. This technique is typically | |
429 | used when the other machine is either too expensive, too slow, too fast, | |
430 | or not available, perhaps because it hasn't yet been built. The native, | |
431 | interpreting program is called a @emph{software emulator}. | |
432 | ||
433 | The @sc{gnu} Development Tools do not currently include any software | |
434 | emulators. Some do exist and the @sc{gnu} Development Tools can be | |
435 | configured to create simple cross development environments for with | |
436 | these emulators. More on this later. | |
437 | ||
438 | The second type of emulation is when source intended for some other | |
439 | development environment is built into a program intended for the native | |
440 | host. The concepts of operating system universes and hosted operating | |
441 | systems are two such development environments. | |
442 | ||
443 | The Cygnus Support Release of the @sc{gnu} Development Tools can be | |
444 | configured for one such emulation at this time. | |
445 | ||
446 | @example | |
447 | ./configure sun4 -ansi | |
448 | @end example | |
449 | ||
450 | @cindex ANSI | |
451 | @cindex X3J11 | |
452 | @noindent | |
453 | will configure the source such that when built in a sun4 development | |
454 | environment the resulting development environment is capable of building | |
455 | sun4 programs from strictly conforming @sc{ANSI X3J11 C} source. | |
456 | Remember that the environment used to build the tools determines the | |
457 | machine on which this tools will run, so the resulting programs aren't | |
458 | necessarily intended to run on a sun4, although they usually are. Also | |
459 | note that the source for the @sc{gnu} tools is not strictly conforming | |
460 | @sc{ansi} source so this configuration cannot be used to bootstrap the | |
461 | @sc{gnu} tools. | |
462 | ||
463 | ||
464 | @node Simple Cross Environments, Crossing Into Targets, Emulation Environments, A Walk Through | |
465 | @section Simple Cross Environments | |
466 | ||
467 | @example | |
468 | ./configure sun4 -target=a29k | |
469 | @end example | |
470 | ||
471 | @noindent | |
472 | will configure the tools such that when compiled in a sun4 development | |
473 | environment the resulting development environment can be used to create | |
474 | programs intended for an a29k. Again, this does not necessarily mean | |
475 | that the new development environment can be run on a sun4. That would | |
476 | depend on the development environment used to build these tools. | |
477 | ||
478 | Earlier you saw how to configure the tools to build a native development | |
479 | environment, that is, a development environment that runs on your sun4 | |
480 | and builds programs for your sun4. Let's pretend that you use stage3 to | |
481 | build this simple cross configuration and let's call the new development | |
482 | environment gcc-a29k. Remember that this is a native build. Gcc-a29k | |
483 | is a collection of native programs intended to run on your sun4. That's | |
484 | what stage3 builds, programs for your sun4. Gcc-a29k represents an a29k | |
485 | development environment that builds programs intended to run on an a29k. | |
486 | But, remember, gcc-a29k runs on your sun4. Programs built with gcc-a29k | |
487 | will run on your sun4 only with the help of an appropriate software | |
488 | emulator. | |
489 | ||
490 | @cindex Simple cross | |
491 | @cindex Crossing to | |
492 | Building gcc-a29k is also a bootstrap but of a slightly different sort. | |
493 | We call gcc-a29k a @emph{simple cross} environment and using gcc-a29k to | |
494 | build a program intended for a29k is called @emph{crossing to} a29k. | |
495 | Simple cross environments are the second category of cross development | |
496 | environments. | |
497 | ||
498 | ||
499 | @node Crossing Into Targets, The Three Party Cross, Simple Cross Environments, A Walk Through | |
500 | @section Crossing Into Targets | |
501 | ||
502 | @example | |
503 | ./configure a29k -target=a29k | |
504 | @end example | |
505 | ||
506 | @noindent | |
507 | will configure the tools such that when compiled in an a29k development | |
508 | environment, the resulting development environment can be used to create | |
509 | programs intended for an a29k. Again, this does not necessarily mean | |
510 | that the new development environment can be run on an a29k. That would | |
511 | depend on the development environment used to build these tools. | |
512 | ||
513 | If you've been following along this walk through, then you've already | |
514 | built an a29k environment, namely gcc-a29k. Let's pretend you use | |
515 | gcc-a29k to build the current configuration. | |
516 | ||
517 | Gcc-a29k builds programs intended for the a29k so the new development | |
518 | environment will be intended for use on an a29k. That is, this new gcc | |
519 | consists of programs that are foreign to your sun4. They cannot be run | |
520 | on your sun4. | |
521 | ||
522 | @cindex Crossing into | |
523 | The process of building this configuration is another a bootstrap. This | |
524 | bootstrap is also a cross to a29k. Because this type of build is both a | |
525 | bootstrap and a cross to a29k, it is sometimes referred to as a | |
526 | @emph{cross into} a29k. This new development environment isn't really a | |
527 | cross development environment at all. It is intended to run on an a29k | |
528 | to produce programs for an a29k. You'll remember that this makes it, by | |
529 | definition, an a29k native compiler. @emph{Crossing into} has been | |
530 | introduced here not because it is a type of cross development | |
531 | environment, but because it is frequently mistaken as one. The process | |
532 | is @emph{a cross} but the resulting development environment is a native | |
533 | development environment. | |
534 | ||
535 | You could not have built this configuration with stage3, because stage3 | |
536 | doesn't provide an a29k environment. Instead it provides a sun4 | |
537 | environment. | |
538 | ||
539 | If you happen to have an a29k lying around, you could now use this fresh | |
540 | development environment on the a29k to three-stage these tools all over | |
541 | again. This process would look just like it did when we built the | |
542 | native sun4 development environment because we would be building another | |
543 | native development environment, this one on a29k. | |
544 | ||
545 | ||
546 | @node The Three Party Cross, , Crossing Into Targets, A Walk Through | |
547 | @section The Three Party Cross | |
548 | ||
549 | So far you've seen that our development environment source must be | |
550 | configured for a specific host and for a specific target. You've also | |
551 | seen that the resulting development environment depends on the | |
552 | development environment used in the build process. | |
553 | ||
554 | When all four match identically, that is, the configured host, the | |
555 | configured target, the environment presented by the development | |
556 | environment used in the build, and the machine on which the resulting | |
557 | development environment is intended to run, then the new development | |
558 | environment will be a native development environment. | |
559 | ||
560 | When all four match except the configured host, then we can assume that | |
561 | the development environment used in the build is some form of library | |
562 | emulation. | |
563 | ||
564 | When all four match except for the configured target, then the resulting | |
565 | development environment will be a simple cross development environment. | |
566 | ||
567 | When all four match except for the host on which the development | |
568 | environment used in the build runs, the build process is a @emph{cross into} | |
569 | and the resulting development environment will be native to some other | |
570 | machine. | |
571 | ||
572 | Most of the other permutations do exist in some form, but only one more | |
573 | is interesting to the current discussion. | |
574 | ||
575 | @example | |
576 | ./configure a29k -target=sun3 | |
577 | @end example | |
578 | ||
579 | @noindent | |
580 | will configure the tools such that when compiled in an a29k development | |
581 | environment, the resulting development environment can be used to create | |
582 | programs intended for a sun3. Again, this does not necessarily mean | |
583 | that the new development environment can be run on an a29k. That would | |
584 | depend on the development environment used to build these tools. | |
585 | ||
586 | If you are still following along, then you have two a29k development | |
587 | environments, the native development environment that runs on a29k, and | |
588 | the simple cross that runs on your sun4. If you use the a29k native | |
589 | development environment on the a29k, you will be doing the same thing we | |
590 | did a while back, namely building a simple cross from a29k to sun3. | |
591 | Let's pretend that instead, you use gcc-a29k, the simple cross | |
592 | development environment that runs on sun4 but produces programs for | |
593 | a29k. | |
594 | ||
595 | The resulting development environment will run on a29k because that's | |
596 | what gcc-a29k builds, a29k programs. This development environment will | |
597 | produce programs for a sun3 because that is how it was configured. This | |
598 | means that the resulting development environment is a simple cross. | |
599 | ||
600 | @cindex Three party cross | |
601 | There really isn't a common name for this process because very few | |
602 | development environments are capable of being configured this | |
603 | extensively. For the sake of discussion, let's call this process a | |
604 | @emph{three party cross}. | |
605 | ||
606 | @node Final Notes, Index, A Walk Through, top | |
607 | @chapter Final Notes | |
608 | ||
609 | By @emph{configures}, I mean that links, Makefile, .gdbinit, and | |
610 | config.status are built. Configuration is always done from the source | |
611 | directory. | |
612 | ||
613 | @table @code | |
614 | ||
615 | @item ./configure @var{name} | |
616 | configures this directory, perhaps recursively, for a single host+target | |
617 | pair where the host and target are both @var{name}. If a previous | |
618 | configuration existed, it will be overwritten. | |
619 | ||
620 | @item ./configure @var{hostname} -target=@var{targetname} | |
621 | configures this directory, perhaps recursively, for a single host+target | |
622 | pair where the host is @var{hostname} and target is @var{targetname}. | |
623 | If a previous configuration existed, it will be overwritten. | |
624 | ||
625 | @item ./configure -subdirs @var{hostname} -target=@var{targetname} | |
626 | creates a subdirectories @file{H-@var{hostname}} if @var{hostname} is @var{targetname} or | |
627 | @file{X-@var{hostname}-@var{targetname}} if it is not and configures the new directory. | |
628 | ||
629 | @end table | |
630 | ||
631 | @menu | |
632 | * Hacking Configurations:: Hacking Configurations | |
633 | @end menu | |
634 | ||
635 | @node Hacking Configurations, , Final Notes, Final Notes | |
636 | @section Hacking Configurations | |
637 | ||
638 | The configure scripts essentially do three things, create subdirectories | |
639 | if appropriate, build a @file{Makefile}, and create links to files, all | |
640 | based on and tailored to, a specific host+target pair. The scripts also | |
641 | create a @file{.gdbinit} if appropriate but this is not tailored. | |
642 | ||
643 | The Makefile is created by prepending some variable definitions to a | |
644 | Makefile template called @file{Makefile.in} and then inserting host and | |
645 | target specific Makefile fragments. The variables are set based on the | |
646 | chosen host+target pair and build style, that is, if you use | |
647 | subdirectories or not. The host and target specific Makefile may or may | |
648 | not exist. | |
649 | ||
650 | @itemize @bullet | |
651 | ||
652 | @item | |
653 | Makefiles can be edited directly, but those changes will eventually be | |
654 | lost. Changes intended to be permanent for a specific host should be | |
655 | made to the host specific Makefile fragment. This should be in | |
656 | @file{./config/mh-@var{host}} if it exists. Changes intended to be | |
657 | permanent for a specific target should be made to the target specific | |
658 | Makefile fragment. This should be in @file{./config/mt-@var{target}} if | |
659 | it exists. Changes intended to be permanent for the directory should be | |
660 | made in @file{Makefile.in}. To propogate changes to any of these, | |
661 | either use @code{make Makefile} or @code{./config.status} or | |
662 | re-configure. | |
663 | ||
664 | @end itemize | |
665 | ||
666 | @page | |
667 | @node Index, , Final Notes, top | |
668 | @appendix Index | |
669 | ||
670 | @printindex cp | |
671 | ||
672 | @contents | |
673 | @bye | |
674 | ||
675 | @c Local Variables: | |
676 | @c fill-column: 72 | |
677 | @c End: |