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