[CsMain] Build Process

[John A. <joh...@co...>]

Hello all!  I'm new to this list.  I am not a programmer, I'm a Unix
Administrator (Linux/BSD)/Systems Engineer by trade.  Okay, I do a
little J2EE hacking on the side, but that hardly counts.

I've been following the Crystal Space/Crystal Entity Layer/Planeshift
projects for quite some time, and recently I've decided to get
involved.  From what I've heard both Crystal and Planeshift programmers
read this list, so I hope I'm posting to the right place.

Since several fellow linux users were having so much trouble getting the
project to build, I packaged it all up into nice and neat RPMs.  I was a
bit taken aback at what I found while doing so.  The things I found out
about the interaction between these Crystal/CEL and planeshift explains
why so many Linux users have problems building/installing.

The build process of planeshift expects the $CRYSTAL and $CEL
directories to look like they do after a ./configure and jam.  Crystal
and CEL both have the capability to jam install.  When you combine the
--prefix option to ./configure with the jam install capability you have
a proper Unix like installation that follows the Fielsystem Hierarchy
Standard (FHS).  All the binaries, unless otherwise set with ./configure
options, are under $prefix/bin.   The libs, $prefix/lib, the configs,
$prefix/etc.  This is good form and good practice.  In this manner, an
administrator can choose the target directory for his purpose.  If the
admin wants Crystal and CEL to be globally available to users with
permissions in /usr/games he can set --prefix=/usr/games.  If a
developer wants the tree installed in their home, or one doesn't have
root on the target system they can set --prefix=~/CS.

In my opinion planeshift's sources should look for their headers and
libraries in the directory tree created by jam install, and not in the
directory tree that is created by simply building but not installing.
This is important for a number of reasons.

1.) I see Crystal Space/Planeshift going far in the Linux world. If
there are multiple projects that build against Crystal it would be best
if all the projects make systems follow the FHS, and look for Crystal's
headers and libs in the directories they are supposed to be installed
in. (i.e. $prefix/include/CrystalSpace or $includedir, $prefix/lib or
$libdir).  If one project expects $CRYSTAL/include/something.h, then
there should be only one copy of something.h, and all projects should
expect that copy to exist in $CRYSTAL/include/.

2.) Most packaging systems are built around the pretense that all linux
applications follow the FHS.  I had to pull some very creative
symlinking and .spec file trickery to get Planeshift to build against
Crystal Space and CEL after I performed a jam install, essential to
building RPMs.

3.) Modifying the planeshift build process, include statements and
linker options to find Crystal/CEL rescources in standard directories,
and adding an install mechanism to planeshift itself will put
developers, administrators, packagers and end-users on the same page.
This will help the projects expand their user bases and draw more users
and developers.

4.) Disk space.  With the amount of art and code that is going into
these projects, utilizing the full make install method will allow an
admin or user to rm the source tree.  They will keep only the
executables, libraries, config files and data they need to run the
application, as well as the headers and library archives (if any) needed
for future building.   This reduces the footprint of the installed
application.

5.) The FHS way of breaking things down is portable.  In windows, the
application could be setup like: C:\program files\bin, C:\program
files\lib, etc.  Including using C:\Documents and
Settings\%user%\Application Data\planeshift for user-specific information.

6.) No more pesky environent variables.  Crystal's install process can
generate a .config file or similar, and that file can be located and
parsed by CEL's and Planeshift's ./configure scripts.  This can set
Crystal's home, libdir, confdir, etc.

Finally, I would really like see the any user specific information, like
the file that populates the email field and password if saved, be moved
out of the planeshift base directory into $HOME/.planeshift/.  Linux, by
nature, is a multi-user environment.  If I were a planeshift gamer, and
my wife decided to play too, we should be both be able to save
independent user specific rescources in our respective home directories.

I'm not trying to nag.  You guys are doing a great job, keep up the good
work.  The unix make process and FHS has been around forever.  That in
itself isn't a good reason to comply with it.  However, it's been around
forever because it works, and it's what other applications, packaging
systems, users, and administrators expect.   I'll probably be
following/playing this project for quite a while and I plan on
participating in any way I can.

References:  http://www.pathname.com/fhs/  The Filesystem Hierarchy Standard

If you would like to review the RPMs and the .spec files it took to
create them see:
http://chesty.homedns.org:4572/planeshift/

Thank you for taking the time to read this whole tirade.   The good
thing about standards is that there are so many to choose from. :-)