Please keep the compiling guide up to date and complete!

[LigH]

Every now and then I want to keep my sources on a level with either the last release version or the most current development results, and build an own client to test different issues.

Every time I try that, it is always the same question: Which information is the most trustworthy and reliable? The compiling guide, the topics in #planeshift-build or #planeshift-bugs, the personal opinion of one or another developer or associate ... they all often differ, and often result in a build which failed because

a) I should have updated this to the latest version,
b) I should not have updated but kept it at that version number.

Often my only available time to compile is at daytimes where hardly anyone is available to ask. Therefore the compiling guide would be my preferred source. But who is responsible for keeping it up-to-date and complete? I mean, since when did we change to Microsoft Visual Studio 2008 (Visual C++ V.10)? And where is the documentation for this branch in the compiling guide? Not to mention the expectable switch to GIT for CrystalSpace, which will be even more annoying for Windows users (TortioseGIT even relies on GitBash).

I am no C++ programmer. I have hardly any experience with the concepts of this compiler and IDE. I can only use it to some extent, and I need to rely on information given by people with more experience.

If there are really as many regular code developers for PlaneShift as I know existing (means: 2..4 persons), then there is no surprise that we lack of manpower already for the documentation.

[Gilrond]

I had hard time with compiling it and figuring proper dependencies configuration as well.

[Talad]

The compiling guide is the most up to date and the one to refer to.

http://planeshift.svn.sourceforge.net/viewvc/planeshift/trunk/docs/compiling.html

It's made for developers anyway, not players.

[LigH]

The Compiling Guide is not exactly "up to date".

The Win32 release package was built with the MS Visual Studio 2008 (MS Visual C++ v10). The Compiling Guide contains no details about how to set up this specific IDE. But instead, it still contains MSVS versions so old that CrystalSpace and PlaneShift don't support them well anymore.

A prerequisite for testers is to be able to compile the client to the current state of development sources and to use the debugger. This is about as much as I could use MSVS 2008, even while not exactly being a C++ programmer.

[raline]

Not sure whether this has anything to do with it being out of date or not, but I still haven't been able to get the planeshift client to compile and run. It's mysteriously unable to locate the cal3d plugin even though /usr/local/lib/crystalspace-2.1/sprcal3dldr.so is present and functional.

[Aiwendil]

Got CRYSTAL set and "/usr/local/lib/crystalspace-2.1" in your LD_LIBRARY_PATH?

[raline]

Yes, that's fine. I did end up figuring out what's wrong: nothing that uses crystalspace works properly unless I cd to its source directory (which implies that 'jam install' was a waste of time, or possibly that another version is interfering even though I've set the CRYSTAL variable). Unfortunately planeshift also doesn't work unless I cd to its source directory. Fortunately I still have the official distribution.

[novacadian]

Yes, that's fine. I did end up figuring out what's wrong: nothing that uses crystalspace works properly unless I cd to its source directory .... planeshift also doesn't work unless I cd to its source directory.

This really sounds to me that you do not have your paths set correctly. Below is what my system (Red Hat Linux) needs set :

export LD_LIBRARY_PATH=$HOME/development/cal3d/src/cal3d/.libs/:$LD_LIBRARY_PATH
export CRYSTAL=$HOME/development/cs
export LD_LIBRARY_PATH="$HOME/development/cal3d/src/cal3d/.libs/:$HOME/development/cs/:"$LD_LIBRARY_PATH

- Nova

[LigH]

Your LD_LIBRARY_PATH definition appears to me like an "L-System" fractal... aren't you repeating parts of it?

[Aiwendil]

(which implies that 'jam install' was a waste of time

Yep, needs more effort to make a system wide CS install useable (and for sure a different LD_LIBRARY_PATH and CRYSTAL as stated in the guide). Also I see no real reason why making a system-wide install...and it's not included in the compile guide. By following the guide it works fine...and there is also far less of a chance to mess up your system if you stay with installing everything just locally for a user.

And it's true that PS only works from it's source directory. It needs to find the config files and when starting from anywhere else it has no clue where to look. This is true for the binary release as well...that's why "cd $(dirname $0)" is the first line of the wrapper script to start PS. But shouldn't be too hard to create a shell script that can be started from everywhere.
But this shouldn't be true for CS applications. I can start "walktest" from wherever I want...as long as CRYSTAL points to the right directory.

@nova. Those PATH won't work for a system wide CS install via "jam install"

[novacadian]

@nova. Those PATH won't work for a system wide CS install via "jam install"

No, the $HOME is the dead give away for that one.

- Nova