|<< Prev||- Up -||Next >>|
configure script can be parametrized by (1) a site configuration file that provides values for certain shell variables, (2) by command line options which may override these values. We recommend that you create a site configuration file for Mozart since this is much easier than to remember what options to supply on the command line. For example create the file
~/mozart.config and set the environment variable
CONFIG_SITE prior to invoking the configure script:
setenv CONFIG_SITE ~/mozart.config
Below, we always describe command line options and related configuration variables together. They are always displayed with their default value or implied setting. Other possible values are described in the text. If a default option is
--enable-foo then you can supply
--disable-foo to turn it off (and reciprocally). If the default value for a configuration variable
yes, then you can set it to
no to turn it off.
You can change the default installation directory to e. g.
prefix=$HOME/mozart-install. The installation directory can also be overriden when invoking
make install by supplying an overriding setting for the make variable
PREFIX on the command line:
% make install PREFIX=$HOME/mozart-install
When you configure and attempt to build the Mozart system, you may discover that some library or package is missing, or that the installed version is too old, or that it happens to be installed in a very strange place. In this case, it may be convenient to install up to date versions of such libraries and packages in a location of your own choosing. For example, if you configure and build a missing package using
--prefix=$HOME, it will normally install its include files into
$HOME/include and its libraries into
$HOME/lib. In that case, when you configure Mozart, you could supply the argument:
to indicate where to look first find additional include files. There are also specific options for specific packages, and they are documented later, but our experience is that putting everything in one extra location is much more convenient.
Similar to the above, but for libraries.
The ``contributions'' are not an intrinsic part of the Mozart distribution. Often they require that you install additional packages: for example the
gdbm contribution requires that you install the gdbm package. Some have not yet been ported to Windows.
By default, the contributions are configured and built. You can completely omit them using
Contributions can be enabled/disabled individually. For example, to enable (or disable) the micq contribution (a Mozart Instant Messenger) you can specify
Processing the documentation requires the contributions (Section 7.2). Also you need additional packages such as LaTeX, netpbm, ghostscript, and a very recent version of nsgmls.
You can omit the documentation using
Specify the documents to be automatically processed by recursing into their directories. The special value
all indicates that all documents should be processed.
directory where java executables and wrappers reside.
select implementation of java threads.
Construct CHM table of contents files (for windows)
The emulator has quite a few configuration parameters.
Overrides the default C++ compiler. Noone has ever needed this option (or lived to tell).
Enabling this option causes the C++ compiler to become frighteningly anal retentive and to print out all sorts of warnings.
When this option is enabled, every warning from the C++ compiler will cause the build process to fail. This is only really useful for the developers of the system.
Compiler options to use when optimizing, profiling, and debugging respectively. Don't use these! See
Mozart needs the GNU Multiple Precision Arithmetic Library also known as
gmp. You can set the variables to point to the directories where the library and the
gmp.h include file are to be found. The command line option can be used to set both variables to the same directory argument. However, see
--with-lib-dir for the more general method that we now recommend.
zlib, the General Purpose Compression Library. The details are as above and we also recommend to use
--with-ccmalloc enables the use of the debugging malloc library. Only for developers.
Select the optimization settings:
--enable-opt=yes for maximum optimization,
--enable-opt=debug for debugging the emulator,
--enable-opt=profile for profiling,
--enable-opt=rsp also for profiling, but only if you happen to be Ralf Scheidhauer.
yes, the emulator becomes marginally faster at the expense of greater compilation times (you might want to go out for coffee while compiling
emulate.cc, which contains the bytecode emulation loop). With
debug, the emulator itself becomes much slower as there are no optimizations, no in-lining, and zillions of assertions are constantly being checked.
By default, the emulator uses threaded byte code if possible, unless
--enable-opt=debug. Turning this off would be foolish.
By default, the emulator uses fast register access.
By default, the emulator uses register optimization.
By default, all boot modules are linked dynamically. Setting this variable to
yes will link them statically. You should only do this if DLLs cannot be made to work on your platform.
Use this option to link with the malloc function in object file FILE. This can be useful if your system malloc is broken. This option is overriden by
Whether to enable support for virtual sites. The default depends on whether virtual sites can be supported on your platform, i. e. it depends on support for shared memory.
|<< Prev||- Up -||Next >>|