Here are specific installation instructions for Crystal Space on
Unix/Linux systems.  Before reading this file, you should read
INSTALL.General.


------------------------
  Editing the Makefile
------------------------

The file 'user.mak' (which you can find in 'CS/mk') is normally
the only makefile that you should worry about. Edit it and see if all
options are suitable for you.  Above I already explained how you can
edit this file to add/remove PNG and JPEG support.

Some other important options in 'user.mak' are:

    DO_ASM=... (possible values: 'yes' or 'no')
        With this option you can disable all assembler optimizations
	present in CS. Note that there is currently only assembler currently
	for Intel so this option has no effect otherwise.
	The default for this option is 'yes' if you are compiling for
	optimization (see above option). Otherwise it is 'no' (because
	debugging interferes with the assembler).

    DO_SHM=... (possible values: 'yes' or 'no')
        When this option is set to 'yes', CS will be linked with the XSHM
	(Shared Memory Extension) libraries. This option is set to 'yes'
	in all system dependent makefiles that require it. There is not
	much reason to set this option to 'no' because Crystal Space can
	check at runtime if the XSHM option is present or not. The only
	reason to disable it is if you don't have the libraries installed
	on your system (which should not happen often).

    DO_PNG, DO_GIF, DO_TGA, and DO_JPG (possible values: 'yes' or 'no')
        The DO_PNG and DO_JPG options are explained above. DO_GIF and DO_TGA
	are for controlling GIF and TGA graphics file loading. Do not
	disable DO_GIF since all current level contain GIF files. It is
	not useful to disable DO_TGA because it does not need any external
	library and it does not require much code in CS.

    MEM=...
        This is a flag which is definitelly not for the beginner. It enables
	a memory debugger which is in Crystal Space. Use only if you know
	what you are doing.

-----------------------
  Compiling the Thing
-----------------------

Ok, enough talk.  Let's really compile it! The makefiles require GNU make.
I assume that 'make' is GNU make in the text below.  If this is not the
case then substitute 'gmake', 'gnumake' or whatever GNU make is called on
your system.

It is NOT possible to make Crystal Space using any other makefile
(unless by doing it manually of course)!

First you need to configure the makefiles for your system. If you are
on Linux you can do this as follows:

	make linux USE_DLL=yes

This indicates that we are going to compile for linux and use dynamic
linking (preferable). If you don't want to use the dynamic libraries you
can set USE_DLL=no. That will generate one big executable.

Other options you have here are:
	linux
	solaris
	irix
	freebsd
	beos
	os2gcc
	os2wcc
	djgpp (only with USE_DLL=no)
	macosxs
	openstep
	nextstep
	win32vc

Optionally you can now do:

	make depend

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 recompiling.

Then you need to do the following:

	make apps

If you selected USE_DLL=yes then this will generate an executable and
drivers (extension *.so) for the software renderer, a 2D driver,
and some network drivers. If you selected USE_DLL=no then only the
executable is generated and the drivers are contained in that executable.

If you selected USE_DLL=yes then you need to register the drivers
(this only needs to be done once) with the 'csregsvr' utility that was
also compiled by 'make all'. Do this as follows:

	./csregsvr ./*.so

If all is well this should register all drivers so
that Crystal Space will be able to load them dynamically. This step
is not needed with USE_DLL=no. The result of registration is put in
csCOM.cfg which needs to be in the same directory as the executable.
The csCOM.cfg which comes with CS is already pre-registered so the
above step may actually not be needed. But it is best to try it to
make sure that all libraries are correctly compiled. Note that it
does not do any harm to register them more than once.


Now you can run the executable 'walktest'.
(see the original 'INSTALL' file for running instructions).


-----------------------------------------------
    Compiling with other 3D and 2D drivers
-----------------------------------------------

The makefiles are normally configured only for the software renderer
and some default 2D driver. Here are some other options:

	- OpenGL with X11
	- Glide with X11
	- Software with SVGALIB
	- Software with GGI

To compile those drivers edit mk/system/linux.mak (or mk/system/solaris.mak)
and edit the 'DRIVERS' statement as explained in the comments in the
beginning. Then do 'make all' again and register the new drivers.

The software renderer can run with the X11, SVGALIB, or GGI drivers. If
the GGI_DISPLAY environment variable is defined it will choose the GGI
driver. Otherwise if DISPLAY is defined it will choose the X11 driver.
If that fails it will try the SVGALIB driver. There is no need to recompile
the program.

To select another 3D rasterizer you need to edit cryst.cfg and change
the DRIVER setting. Or else you can run Crystal Space as follows:

	walktest -driver opengl


-----------------------
    MazeD
-----------------------

MazeD is a beta level editor for Crystal Space. It works very nicely
but it is not yet fully useable for real level editing. Note that MazeD
also requires a 2D and 3D driver so these need to be compiled as well.


-------------------------------
  Where are the Object Files?
-------------------------------

The build process places all object files and 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/LINUX/INTEL/optimize'.  However if you compile on a Solaris
system for Sparc with debugging enabled then all objects files end up in
'CS/out/SOLARIS/SPARC/debug'.

The reason for this directory structure is that it simplifies the
compilation of CS 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 over-
writing the other.
