[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section covers all of the Unix-style platforms supported by Crystal Space, including Linux, FreeBSD, NetBSD, Solaris, etc.
Note that the X11 version of Crystal Space optionally supports the MIT Shared Memory Extension (MIT-SHM). This makes Crystal Space run much faster if your server supports it. By default Crystal Space assumes that your server supports MIT-SHM. It will automatically auto-detect if your server does not support it, so you can safely leave this option enabled.
The makefiles require GNU make, which is typically named `make' on most systems. If this is not the case then substitute `gmake', `gnumake' or whatever GNU make is called on your system. It is not possible to build Crystal Space using any other make system.
You first need to configure the makefiles for your platform. You do this by running the configuration script. For example, from within the `CS' directory:
./configure |
If you wish to build with debugging information enabled, use this command, instead:
./configure --enable-debug |
By default, the project is configured to build plugin modules, rather than linking everything together into a single executable, however, if you would like everything linked together (though this is not recommended), you can configure with:
./configure --disable-plugins |
For a list of useful configuration options, invoke:
./configure --help=short |
You can optionally invoke the `depend' target to make sure that all dependencies are correct. This is only important if you intend to make changes to the sources and want to be sure that all files will be recompiled that are in need of recompilation. You can, however, can safely omit this step if desired.
make depend |
Then you need to do the following to actually build the entire project:
make -k all |
If you configured for plugins (that is, you did not use `--disable-plugins', then this will generate an executable and plugin modules (with extension `*.so' on Linux and most Unix platforms) for the 3D renderers, 2D drivers, and other modules. If you did not choose to build plugin modules, then only the executable is generated and the drivers are incorporated in the executable.
Optional: Only perform this step if you are developing a brand new plug-in module or changing the SCF identification of an existing one. If you opted to build plugin modules, then you may need to register the drivers with the SCF system. This generally only needs to be done once. The registration information is maintained in the file `scf.cfg'. However, typically this file is already up-to-date, so usually you can skip this step altogether. Only perform this step if the system is unable to locate the drivers or if you are actively developing a driver and changing registration information. The program to register plug-ins is called scfreg, and it was also compiled by `make -k all'. To run it, type:
./scfreg *.so |
If all is well this should register all drivers so that Crystal Space will be able to load them dynamically. If your platform uses a file extension other than `*.so' for plug-in modules, then alter the command appropriately. This step is not needed when plugin modules are not built separately.
Now you can run the executable `walktest'.
The software renderer can run with the X11 or SVGAlib drivers. If the `DISPLAY' environment variable is defined it will choose the X11 driver, otherwise it will try the `SVGAlib' driver, if SVGAlib is available on your platform. There is no need to recompile the program.
To select another 3D rasterizer you need to edit your local configuration file `CS/data/config/user.cfg'. Add the following line to select OpenGL for all applications:
Global.System.Plugins.iGraphics3D = crystalspace.graphics3d.opengl |
Alternately, you can choose the OpenGL renderer from the command-line:
walktest -video=opengl |
The build process places all object files and static libraries in the directory `CS/out'. This directory contains subdirectories for the operating system and processor architecture. For example, if you compile on Linux for Intel with optimization then all object files will end up in `CS/out/UNIX/X86/optimize'. However if you compile on a Solaris system for Sparc with debugging enabled then all objects files end up in `CS/out/UNIX/SPARC/debug'.
The reason for this directory structure is that it simplifies the compilation of Crystal Space both with and without optimization, as well as when using a cross-compiler to generate object files for other processor architectures.
Another advantage is for people who share the same directory structure for different systems. For example, if Crystal Space is located on a shared directory for both a Solaris system and a Linux system then this arrangement allows the package to be built for each system without overwriting the other.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |