Status report:
Preparation:
- Mac users must set up a more current version of jam than is available from the dev tools. I advise installing from Fink (\"fink install jam\") which will go and build a 2.4 version of jam.
- PlaneShift requires libogg and libvorbis. Again, \"fink install libogg\" and \"fink install libvorbis\".
- PlaneShift requires the freetype2 font library to be built and the associated CS plugin. Again, \"fink install freetype2\" will get you a working version of that library.
- PlaneShift will also require, in all likelihood, a top-of-tree libtool configured for building mac dynalibs. I\'m using the \"fink install libtool14\" at the moment, and will drop back to shipping libtool once I\'ve figured out all of the problems.
- Install the December 2002 dev tools from Apple; this contains the most recent gcc 3.1 toolchain.
- A server build of PlaneShift will require mysql. Since the network code doesn\'t negotiate endian-ness, you\'re going to have to run a server as well as the client, so be prepared to have this.
- Also note that shortly, evidently, you\'ll need python installed; not the Apple-shipped one either, but a proper python build from more recent deliveries. You\'ll also need swiv. Both are available on fink, but fink also wants to build swiv support for ruby, tcltk, and a handful of other scripting languages, so Buyer Beware on using fink\'s swiv install.
Progress:
CS: CrystalSpace compiles without *too* many problems. In order to build components, the standard CS build needs to be done, with the addition of two components. The following problems were encountered:
- CS doesn\'t seem to deal well with additional paths being added, and makes some assumptions about where the freetype2 paths are. At some point, I will make some changes to the build process to pick up and remember the paths that were given to it on flags lines, and pass those on into the cs-config command line. This means making the values of CFLAGS, CXXFLAGS, and LDFLAGS \'sticky\' and stored into the makefiles as well as the cs-config script which will pass them on to other dependent builds.
- Don\'t forget to build those extra plugins. You can always do it later, but what a task.
- Do use \'configure\' and not \'make macosx\'.
- Dependent projects *need* the ability to get the required link lines needed to produce a binary, shared library, or module on a given system. Currently, CS knows this, but doesn\'t pass on the link information. If it told us this, we could rely on CS to correctly tell us how to build a plugin for CS. This means extending cs-config to provide ld-flags for a binary as well as ld-flags for a plugin.
CEL: CEL\'s build process isn\'t quite there yet. Some modifications were made to the linker lines so that MacOS X modules get built correctly; however, a bug in TOT CS means that the cs-config isn\'t passing in the -framework LD flags properly. For now, hack cs-config; hopefully, the cs-config script will get fixed to include these flags, as well as the aforementioned cflags/ldflags However, once that modification is made, CEL will happily ./configure and run.
PS: PS has needed a multitude of small fixes, mostly to the location of headers (which is different on BSD from Linux platforms in some cases) as well as one or two places where Linux-specific flags are used. Those changes, I believe, are already in TOT ps.
The greater problem with PS at the moment is, as it is a libtool based build, the building of the dynamically-linked plugins is currently failing; libtool isn\'t able to provide a dynamic link library where you are linking against .a files that weren\'t built by libtool initially. I\'ll get around this by changing the build system to build temporary libtool archives of the core CS libraries, which should fix the problem. However, the greater problem remains that we can\'t use the information from the CS build to find out how to build a plugin; and it would be better if we could reuse that information and leave it to CS to figure out how to build those plugins in the first place. Alternately, I could build and link the whole lot statically, and build CS and CEL as static libraries. Neither really matters a whole lot.
What\'s working:
The whole thing builds, basically, and you can run all tests in CS. CS performance on my DP500 Radeon 8500 system is *not* brilliant, and I\'m not sure why; it\'s dropping to software, using something that isn\'t supported in the 8500 hardware. I\'ll have a whack at looking at the OpenGL profiler tonight and see if I can see where we\'re using an unsupported GL extension.
CEL\'s celtst runs. It isn\'t building a .app, but frankly, who gives a damn. Run it from the commandline.
PlaneShift\'s pssetup script is horribly broken, and missing support for the mac bundle identities; I\'ve cleaned it up and added support. Once you run that, it happily runs the ps setup tool that lets you choose your resolution, and decide whether or not you want music and/or sound.
However, psclient cannot start up with its plugins statically linked to a dyna-linked CS/CEL installation. Until I solve the build problem preventing dynamic linking with libtool when linking to .a files generated by CS, we\'re stuck here.
Server starts up. Obviously can\'t test it.
That\'ll have to do until tonight, when I have a chance to look further.
