1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
Configuration
Last Mod Fri Apr 12 13:32:56 PDT 1991, by rich@sendai
"Theory":
In this document, the word "host" refers to the environment in which
this source will be compiled. "host" and "host name" have nothing to
do with the proper name of your host, like "ucbvax", "prep.ai.mit.edu"
or "att.com". Instead they refer to things like "sun4" and "dec3100".
Forget for a moment that this particular directory of source is the
source for a development environment. Instead, pretend that it is the
source for a simpler, more mundane, application, say, a desk
calculator.
Source that can be compiled in more than one environment, generally
needs to be set up for each environment explicitly.
The word "target" refers to the environment produced by compiling this
source and installing the resulting binaries.
For example, if configured for host sun4 and target sun4, this implies
that we will compile on a sun4 to create a sun4 compilation
environment. If configured for host sun3 and target a29k, this
implies that we will compile on a sun3 to create an a29k compilation
environment.
Host sun3 only implies that the source will be compiled on a sun3. In
fact, it need not be actually compiled on a sun3. If the appropriate
native development tools, header files, libraries, and operating
system support were available on a foobox, then source configured for
a sun3 could be compiled on a foobox, resulting in a development
environment for, using the previous example host+target pair, "a29k"
on the foobox. Similarly, if the appropriate cross development tools,
header files, and libraries were available on a dec3100, then source
configured for host sun3 could be cross compiled to create an a29k
development environment intended to be run on a sun3.
Usage:
Gdb's config has features not yet present in the uniform configuration
scheme described here. For this reason, configuration of gdb must
currently be done separately from that of the rest of this package.
This will be corrected soon. For more information on the
configuration of gdb, please refer to the documents in gdb.{your
target} if it exists, otherwise gdb.
By "configures", I mean that links, Makefile, .gdbinit, and
config.status are built. Configuration is always done from the source
directory.
* "./configure name" configures this directory, perhaps
recursively, for a single host+target pair where the host and target
are both "name". If a previous configuration existed, it will be
overwritten.
* "./configure +host=hostname targetname" configures this
directory, perhaps recursively, for a single host+target pair where
the host is hostname and target is targetname. If a previous
configuration existed, it will be overwritten.
* "./configure +forcesubdirs +host=hostname targetname" creates
a subdirectories Host-hostname and
Host-hostname/Target-targetname and configures
Host-hostname/Target-targetname. For now, makes should be
done from Host-hostname/Target-targetname. "./configure +f
name" works as expected. That is, it creates Host-name and
Host-name/Target-name and configures the latter.
Hacking configurations:
The configure scripts essentially do three things, create
subdirectories if appropriate, build a Makefile, and create links to
files, all based on and tailored to, a specific host+target pair. The
scripts also create a .gdbinit if appropriate but this is not
tailored.
The Makefile is created by prepending some variable definitions to a
Makefile template called Makefile.in and then inserting host and
target specific Makefile fragments. The variables are set based on
the chosen host+target pair and build style, that is, if you use
subdirectories or not. The host and target specific Makefile
may or may not exist. If fragments
* Makefiles can be editted directly, but those changes will eventually
be lost. Changes intended to be permanent for a specific host
should be made to the host specific Makefile fragment. This should
be in ./config/hmake-host if it exists. Changes intended to be
permanent for a specific target should be made to the target
specific Makefile fragment. This should be in ./config/tmake-target
if it exists. Changes intended to be permanent for the directory
should be made in Makefile.in. To propogate changes to any of
these, either use "make Makefile" or re-configure from the source
directory.
* configure can be editted directly, but those changes will eventually
be lost. Changes intended to be permanent for a specific directory
should be made to configure.in. Changes intended to be permanent
for all configure scripts should be made to configure.template.
Propogating changes to configure.in requires the presence of
configure.template which normally resides in the uppermost directory
you received. To propogate changes to either configure.template or
a configure.in, use "configure +template=absolutepathtothetemplate".
This will configure the configure scripts themselves, recursively if
appropriate.
* "configure -srcdir=foo" is not supported yet. At the moment, things
will probably be configured correctly only for leaf directories, and
even they will not have paths to libraries set properly.
|
