apt-get or rpm. Additionally, there are equally SAWEET frontends for said package management systems to make the software installation process even cleaner and more user-friendly (for example, synaptic is a good li'l GUI buddy for apt-get).If you aren't using a package management system, I highly recommend you start doing so, because it makes locating and installing software WAY easier -- much easier even than installing stuff in Winders -- no manual downloading or running installers or anything.
Apart from the Linux-distribution-specific package management details, these instructions should, in theory, suffice for any flavor of Unix, possibly including Mac OS X. Maybe even for Cygwin under Winderps, but just who the hell knows with that retarded operating system.
Instructions for the unwashed masses:
Through whatever your preferred means, install the development versions of the SDL, SDL_image and FreeType2 libraries. The specific package names and versions may vary from the following example for your specific package management system.
apt-get install libsdl1.2-dev libsdl-image1.2-dev libfreetype6
Go to a directory appropriate to dump source code and checkout the XuqRijBuh game engine source via Subversion using the following command.
svn co https://svn.sourceforge.net/svnroot/xuqrijbuh xuqrijbuh
Download the XuqRijBuh resources and unzip it (later instructions assume you've squirted it into the xuqrijbuh/trunk directory).
wget http://www.thedods.com/victor/resources.zip && unzip resources.zip -d xuqrijbuh/trunk
Create the configure script. This must be done every time configure.ac is modified.
cd xuqrijbuh/trunk && ./bootstrap.sh
Create a build directory, change directory to it, and Configure. See Configuring A Build if that's what floats your boat.
mkdir debug && cd debug && ../configure --enable-debug --disable-static --enable-nan-sanity-check
Symbolically link the resources directory and then Compile. See Compiling And Build Targets if that's what tickles your pickle.
ln -s ../resources . && make
Your applications are waiting in the build directory, suh. Run them at your leisure.
g++ make autoconf (version 2.59 is known to work) automake (version 1.9 is known to work) libtool (1.5.6 is known to work) svn (a Subversion client)
Implicitly, a Bourne-compatible shell (e.g. sh or bash) is required for make and the auto-tools to work (though I might be on crack).
If you are not installing packages through a package management system, you can find the necessary source or pre-compiled binary packages here:
http://www.libsdl.org/index.php
Look under "Download" for SDL 1.X (1.2 is the most recent as of August 2006). You'll need both the runtime and development libraries. Choose whichever format packages are appropriate for your system.
If you are not installing packages through a package management system, you can find the necessary source or pre-compiled binary packages here:
http://www.libsdl.org/projects/SDL_image/
You'll need both the runtime and development libraries. Choose whichever format packages are appropriate for your system. This library requires others, such as libpng, libjpeg, libtiff, and zlib. Uhh, like, it is left as an exercise to the reader on finding and installing these libs. Ha ha. Serves you right for not using apt-get.
If you are not installing packages through a package management system, you can find the necessary source or pre-compiled binary packages here:
http://download.savannah.gnu.org/releases/freetype/
You want the package of the form ftXXXX.zip (ft221.zip is the most recent as of August 2006) -- the only available format is the source package.
https://svn.sourceforge.net/svnroot/xuqrijbuh
So if you're using the commandline svn client, you would cd to the directory you want to dump the source tree, and issue this command:
svn co https://svn.sourceforge.net/svnroot/xuqrijbuh xuqrijbuh
A directory containing the full source tree, called xuqrijbuh, will be created in your current working directory.
There are three subdirectories of xuqrijbuh:
branches contains development branches of various [sub]trees, when applicable tags contains text files indicating revision numbers for notable landmarks in the tree's development trunk contains the main development tree of the source code -- this is where everyone usually hangs out For general information on XuqRijBuh, go to the SourceForge homepage:
http://sourceforge.net/projects/xuqrijbuh/
http://www.thedods.com/victor/resources.zip
Download this, and unzip it into xuqrijbuh/trunk.
configure, from the xuqrijbuh/trunk directory, you must run the following command.
./bootstrap.sh
This must be run every time configure.ac is modified -- either by you or through svn update.
This uses aclocal, autoheader, libtoolize, automake and autoconf to generate the files necessary for building -- configure and Makefile.in.
The autoconf tool generates the configure script which detects locations and versions of libraries, header files, compilers, tools, etc. in order to make the build process consistent across many platforms (primarily Unices). The file configure.ac is the source file which autoconf reads in order to produce the configure script.
Similarly, automake is a program which automates generation of complicated Makefiles. It uses Makefile.am to generate an analogous instances of Makefile.in, which are in turn used by the configure script to produce Makefile.
Even though the syntax and much of the design detail of these two apps is completely retarded and irrational, they do work very well, and are what facilitate the ubiquitous "configure, make, make install" configuration/compilation/installation commands as used by practically all open-source C/C++ Unix software.
More information on autoconf and automake can be found at http://www.gnu.org/software/autoconf/ and http://www.gnu.org/software/automake/ respectively.
configure script is the central point of control for detecting and specifying system characteristics and other build options. To see what specific options are available, run:
./configure --help
Some useful options include:
--disable-static Causes only dynamically-linked binaries to be produced. --disable-shared Causes only statically-linked binaries to be produced. --enable-debug Turns on debugging symbols, turns off optimizations. --enable-gprof Enables gprof (performance profiling) instrumentation, sets the debug level to 0, and enables optimizations. Must be paired with --disable-shared. --enable-nan-sanity-check Enables specific asserts in the 2D engine system which are useful to detect accidental divide-by-zero errors in game logic code. --with-debug-level=# Specifies the assert threshold -- 0 being the minimum and 3 being the most pedantic. Use with argument 0, 1, 2 or the default value of 3. The default linking behavior is to produce both dynamic and static libraries, but only dynamically-linked executables.
During the development cycle, it is recommended to use options:
--disable-static --enable-debug --enable-nan-sanity-check
For a (statically-linked) release, use:
--disable-shared --with-debug-level=0 --with-arch=XXX
Where XXX is the name of the target architecture (see your compiler's documentation for specific architecture names).
I recommend not running configure in the source directory (xuqrijbuh/trunk), but rather creating a subdirectory (debug or release or profile etc.), hereafter referred to as the "build directory" and running configure from there. For example:
cd xuqrijbuh/trunk mkdir debug cd debug ../configure --disable-static --enable-debug --enable-nan-sanity-check
This will cause the xuqrijbuh/trunk/debug directory to contain all generated files (object, library and executable). Since it is strictly separated from the source tree, it is easy to delete the directory should the need arise to start completely cleanly.
Running configure will produce a Makefile in the build directory which is used by make to build the libraries and applications. This Makefile defines the build targets (the applications and game engine library)
make
in the build directory. This will build the game engine library (in the lib/ subdir) and all application executables (in the build dir). You can also build one or more of the targets specifically, should you not want to waste time building stuff you're not working on or don't care about. As of August 2006, the build targets are:
lib/libxrb.la is the library itself, and produces a libtool library which is linked (statically or dynamically, depending on the configure options used) into each application to produce executables. All projects besides this library are applications. disasteroids is the first full example game implementation provided with XuqRijBuh and as of August 2006, is still under development. guidemo is a demonstration of the GUI system (which is very in-progress as of August 2006), designed to showcase what capabilities are available and how the GUI system behaves. lesson00 lesson01 ... are tutorials intended to teach usage of the game engine library incrementally in small, manageable steps.
Building a target by name is done by specifying it as a parameter to make.
make lib/libxrb.la
Or to build multiple targets,
make disasteroids guidemo
Building an application will cause make to build all its dependencies if necessary (e.g. if the library code has changed, lib/libxrb.la will be rebuilt before linking the application).
For the example applications to run properly, they need access to the resources directory. The easiest way to do this is to create a symlink from the build dir to wherever you unzipped resources.zip. Assuming you unzipped resources.zip into xuqrijbuh/trunk and you're in the build directory -- xuqrijbuh/trunk/debug:
ln -s ../resources .
If you ever run an app, and it fails inexplicably, it's probably because you're a douche bag. Either that or you're missing the resources directory (explained in XuqRijBuh Resources), or you screwed up the above symlink command.
It should be noted that if you made a dynamically-linked build (see configure option --disable-static, the "real" executable is located in the .libs subdirectory of the target, with the prefix lt- and what you thought was the executable is actually a libtool-generated shell script which does some fancy voodoo to set things up for execution of the dynamically-linked binary in the development directory tree. For example, for disasteroids, the binary produced is .libs/lt-disasteroids, and the file disasteroids is the libtool-generated shell script.
Makefile.ams, you can use automake's make install facility (see http://www.gnu.org/software/automake/ for more details). 
1.5.8