![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to INSTALL CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Generator SEGA Genesis emulator] / generator|
Return to INSTALL CVS log | Up to [Generator SEGA Genesis emulator] / generator |
1.1 root 1: Generator specifics
2: ===================
3:
4: When you configure Generator, make sure you look for these lines:
5:
6: Turning on x86 processor optimisations
7: Turning on gcc optimisations
8: Turning on pentium optimisations
9:
10: If you see warnings about lack of optimisation then Generator will
11: be running non-optimally. If you are using gcc version 3 then
12: read on for specific optimisations for this compiler.
13:
1.1.1.4 ! root 14: NOTE: gcc (GCC) 3.2.3 20030415 (Debian prerelease) does not compile
! 15: Generator properly when optimisations are turned on! This may
! 16: be a problem with all gcc 3 versions!
! 17:
1.1 root 18: Generator version
19: =================
20:
21: This source can be compiled for three different types of interface:
22:
1.1.1.3 root 23: --with-svgalib
24: --with-allegro
25: --with-gtk
26: --with-tcltk (deprecated)
27:
28: One and only one of these options must be given to configure.
29:
30: The source also needs a z80 emulation:
31:
32: --with-raze (i386 assembler - uses nasm to compile)
33: --with-cmz80 (portable C)
1.1 root 34:
35: One and only one of these options must be given to configure.
36:
37: Example
38: =======
39:
40: An example compilation:
41:
1.1.1.3 root 42: ./configure --with-gtk --with-raze --prefix=/home/james
1.1 root 43: make
44: make install
45:
1.1.1.2 root 46: Cross compile
47: =============
48:
1.1.1.3 root 49: Generator's build tree should cope well with cross compilation. To
50: compile using djgpp/allegro use:
1.1.1.2 root 51:
1.1.1.3 root 52: PATH=/usr/i586-pc-msdosdjgpp/bin:$PATH ./configure --with-allegro \
53: --with-raze --host=i586-pc-msdosdjgpp --build=i686-pc-linux-gnu \
54: --with-coffasm
1.1.1.2 root 55: PATH=/usr/i586-pc-msdosdjgpp/bin:$PATH make
56:
1.1.1.3 root 57: The option --with-coffasm is for raze compilation - it does two things,
58: it switches to 'coff' output instead of 'elf' with nasm, and it also
59: modifies a macro in raze.asm that inserts underscores before all globals.
1.1.1.2 root 60:
1.1.1.3 root 61: Generator has two binaries 'def68k' and 'gen68k' that need to be run on
62: the host machine, so if you see the error:
1.1.1.2 root 63:
1.1.1.3 root 64: ./def68k: ./def68k: cannot execute binary file
1.1.1.2 root 65:
1.1.1.3 root 66: You will need to copy local versions of def68k and gen68k (that you compiled
67: earlier) into place so that the compilation can continue.
1.1.1.2 root 68:
1.1 root 69: Basic Installation
70: ==================
71:
72: The `configure' shell script attempts to guess correct values for
73: various system-dependent variables used during compilation. It uses
74: those values to create a `Makefile' in each directory of the package.
75: It may also create one or more `.h' files containing system-dependent
76: definitions. Finally, it creates a shell script `config.status' that
77: you can run in the future to recreate the current configuration, a file
78: `config.cache' that saves the results of its tests to speed up
79: reconfiguring, and a file `config.log' containing compiler output
80: (useful mainly for debugging `configure').
81:
82: If you need to do unusual things to compile the package, please try
83: to figure out how `configure' could check whether to do them, and mail
84: diffs or instructions to the address given in the `README' so they can
85: be considered for the next release. If at some point `config.cache'
86: contains results you don't want to keep, you may remove or edit it.
87:
88: The file `configure.in' is used to create `configure' by a program
89: called `autoconf'. You only need `configure.in' if you want to change
90: it or regenerate `configure' using a newer version of `autoconf'.
91:
92: The simplest way to compile this package is:
93:
94: 1. `cd' to the directory containing the package's source code and type
95: `./configure' to configure the package for your system. If you're
96: using `csh' on an old version of System V, you might need to type
97: `sh ./configure' instead to prevent `csh' from trying to execute
98: `configure' itself.
99:
100: Running `configure' takes awhile. While running, it prints some
101: messages telling which features it is checking for.
102:
103: Generator supports these additional options:
104:
105: --with-gcc[=VERSION] GCC optimisation setting
106:
107: By default Generator assumes gcc version 2.95 optimisations
108: but you can specify '2', '3' or 'no' to select 2.95, 3.0 or no
109: optimisations respectively.
110:
111: --with-warnings Turn on gcc warnings
112:
113: This turns on gcc warnings, this is mostly for development
114: purposes.
115:
116: 2. Type `make' to compile the package.
117:
118: 3. Optionally, type `make check' to run any self-tests that come with
119: the package.
120:
121: 4. Type `make install' to install the programs and any data files and
122: documentation.
123:
124: 5. You can remove the program binaries and object files from the
125: source code directory by typing `make clean'. To also remove the
126: files that `configure' created (so you can compile the package for
127: a different kind of computer), type `make distclean'. There is
128: also a `make maintainer-clean' target, but that is intended mainly
129: for the package's developers. If you use it, you may have to get
130: all sorts of other programs in order to regenerate files that came
131: with the distribution.
132:
133: Compilers and Options
134: =====================
135:
136: Some systems require unusual options for compilation or linking that
137: the `configure' script does not know about. You can give `configure'
138: initial values for variables by setting them in the environment. Using
139: a Bourne-compatible shell, you can do that on the command line like
140: this:
141: CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
142:
143: Or on systems that have the `env' program, you can do it like this:
144: env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
145:
146: Compiling For Multiple Architectures
147: ====================================
148:
149: You can compile the package for more than one kind of computer at the
150: same time, by placing the object files for each architecture in their
151: own directory. To do this, you must use a version of `make' that
152: supports the `VPATH' variable, such as GNU `make'. `cd' to the
153: directory where you want the object files and executables to go and run
154: the `configure' script. `configure' automatically checks for the
155: source code in the directory that `configure' is in and in `..'.
156:
157: If you have to use a `make' that does not supports the `VPATH'
158: variable, you have to compile the package for one architecture at a time
159: in the source code directory. After you have installed the package for
160: one architecture, use `make distclean' before reconfiguring for another
161: architecture.
162:
163: Installation Names
164: ==================
165:
166: By default, `make install' will install the package's files in
167: `/usr/local/bin', `/usr/local/man', etc. You can specify an
168: installation prefix other than `/usr/local' by giving `configure' the
169: option `--prefix=PATH'.
170:
171: You can specify separate installation prefixes for
172: architecture-specific files and architecture-independent files. If you
173: give `configure' the option `--exec-prefix=PATH', the package will use
174: PATH as the prefix for installing programs and libraries.
175: Documentation and other data files will still use the regular prefix.
176:
177: In addition, if you use an unusual directory layout you can give
178: options like `--bindir=PATH' to specify different values for particular
179: kinds of files. Run `configure --help' for a list of the directories
180: you can set and what kinds of files go in them.
181:
182: If the package supports it, you can cause programs to be installed
183: with an extra prefix or suffix on their names by giving `configure' the
184: option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
185:
186: Optional Features
187: =================
188:
189: Some packages pay attention to `--enable-FEATURE' options to
190: `configure', where FEATURE indicates an optional part of the package.
191: They may also pay attention to `--with-PACKAGE' options, where PACKAGE
192: is something like `gnu-as' or `x' (for the X Window System). The
193: `README' should mention any `--enable-' and `--with-' options that the
194: package recognizes.
195:
196: For packages that use the X Window System, `configure' can usually
197: find the X include and library files automatically, but if it doesn't,
198: you can use the `configure' options `--x-includes=DIR' and
199: `--x-libraries=DIR' to specify their locations.
200:
201: Specifying the System Type
202: ==========================
203:
204: There may be some features `configure' can not figure out
205: automatically, but needs to determine by the type of host the package
206: will run on. Usually `configure' can figure that out, but if it prints
207: a message saying it can not guess the host type, give it the
208: `--host=TYPE' option. TYPE can either be a short name for the system
209: type, such as `sun4', or a canonical name with three fields:
210: CPU-COMPANY-SYSTEM
211:
212: See the file `config.sub' for the possible values of each field. If
213: `config.sub' isn't included in this package, then this package doesn't
214: need to know the host type.
215:
216: If you are building compiler tools for cross-compiling, you can also
217: use the `--target=TYPE' option to select the type of system they will
218: produce code for and the `--build=TYPE' option to select the type of
219: system on which you are compiling the package.
220:
221: Sharing Defaults
222: ================
223:
224: If you want to set default values for `configure' scripts to share,
225: you can create a site shell script called `config.site' that gives
226: default values for variables like `CC', `cache_file', and `prefix'.
227: `configure' looks for `PREFIX/share/config.site' if it exists, then
228: `PREFIX/etc/config.site' if it exists. Or, you can set the
229: `CONFIG_SITE' environment variable to the location of the site script.
230: A warning: not all `configure' scripts look for a site script.
231:
232: Operation Controls
233: ==================
234:
235: `configure' recognizes the following options to control how it
236: operates.
237:
238: `--cache-file=FILE'
239: Use and save the results of the tests in FILE instead of
240: `./config.cache'. Set FILE to `/dev/null' to disable caching, for
241: debugging `configure'.
242:
243: `--help'
244: Print a summary of the options to `configure', and exit.
245:
246: `--quiet'
247: `--silent'
248: `-q'
249: Do not print messages saying which checks are being made. To
250: suppress all normal output, redirect it to `/dev/null' (any error
251: messages will still be shown).
252:
253: `--srcdir=DIR'
254: Look for the package's source code in directory DIR. Usually
255: `configure' can determine that directory automatically.
256:
257: `--version'
258: Print the version of Autoconf used to generate the `configure'
259: script, and exit.
260:
261: `configure' also accepts some other, not widely useful, options.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.