FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


FIFE 0.4.0 has been released on 15th of January, 2017!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dsrogers

Pages: [1]
Did you reply to the wrong topic?  Because I have no idea what you are quoting.


I'm proposing a change to allow building as a framework with framework dependencies.  Attached are two patches to add support for this, and make it the default on Mac OS X.

First, you still need scons and SWIG from somewhere.  Macports works fine.  These are not runtime dependencies, only compile dependencies.

Second, I've broken it into two patches.  The first one is a the "real" patch, and the second one is a patch for generated files.  Since I have a different version of the autotools that was used to generate the build system for guichan, that diff is big and ugly, but mostly meaningless.  The second patch, I won't discuss.  It's not necessary if you run "autoreconf" yourself after apply the first patch, but you'll need all the autotools installed, and the effect on the finally svn diff will be similar.  It may be worthwhile to remove the generated files from svn and regenerate them prior to creating the tgz for distribution, like most autotools projects.

On to the first diff...

There are three basic pieces.  First is the change to build/  This eliminates all compile dependencies on /opt/local, and relies on frameworks for the dependencies.  The dependencies are expected to be installed into mac-ext.  I've posted a tgz of all the dependencies at  This includes a build of patched guichan, though there is more to the patch to allow rebuilding this.

The big issue with the dependencies right now is that for some of them, I didn't include the tools or instructions to recreate them.  Documentation will be my next step, and it will include all the code and instructions for rebuilding the deps as necessary.  SDL is already built as a framework on the website.  For boost, I have a little makefile that will build the frameworks with install_name_tool after the bjam build has run.  For ogg and vorbis, I tweaked the included xcode build files (mostly changed their install path to be @executable_path/../Frameworks).  The second issue is that I made no effort to get these dependencies working on 10.5.  They may work.  That probably won't.  That's fixable with compiler flags but I don't have 10.5 to test anymore.

The second piece are the changes to ext/SConscript to allow building guichan as a framework.  I've included a makefile that post-processes the built libraries to produce the frameworks.  I've changed ext/SConscript to call ./configure with the needed arguments on darwin, and make sure I call my post-processing makefile before copying the frameworks to mac-ext.   This makefile and perl script are nearly identical to what I use to build boost frameworks, for the curious.  This is not ideal.  The ideal solution would be to fix guichan to build the framework it it's own makefiles.  However I'm not in a hurry to learn libtool and the autotools right now as I'm still learning scons and pythong, and what I have today has the advantage that it works.

The third piece are all the changes to build Fife.framework.  This is mostly creating the right directory structure, and some linker flag changes.  Also symlinks.  The thing I don't like about this patch is that this is my first time with scons, (and probably the second or third time with python) so the symlink tasks feel like an egregious hack.  However it works.

A few more notes:

Since this is designed to be built as an application embedded framework, all the dependences and Fife.framework are expected to reside in "@executable_path/../Frameworks"  Ie. in your application's Frameworks folder.  This means you need to set DYLD_FRAMEWORK_PATH properly to locate the frameworks before you've built your app.  I'm assuming that whoever packages the app is going to want to embed the python framework as well.  py2app has support for this.  Because both of these are going to be embedded, I've changed the default install path of fife, for darwin framework builds to be "dest"

If you type scons install-all, "dest" will contain Fife.framework, libfife.a, and a python directory suitable for adding to your PYTHONPATH.

If you want to run the editor after building fife try this:
$ cd /path/to/fife-root
$ export PYTHONPATH=$(pwd)/dest/python
#(you could also use $(pwd)/engine/python)
$ export DYLD_FRAMEWORK_PATH=$(pwd)/mac-ext
$ cd tools/editor
$ ./

Obviously using py2app to build an is a good next step.

Also, I don't know about packaging but the python directory may be better suited in Fife.framework/Versions/Current/python (with a symlink at Fife.framework/python pointing to Versions/Current/python).  It doesn't really matter how it's packaged, as long as the .app bundle can eventually find it.  Whatever is easiest on py2app is probably best.

I didn't test Fife.framework.  I don't have a C++ fife game handy.  Also, mac-ext contains all of the boost libs, even though most of them aren't required for fife.  As apparently I'm the first person to make boost available as a framework, I made the whole thing available (who knows what C++ games use other parts of boost).

Please give feedback.  This is by no means perfect, it's functioning.

Ack -- patches too large:

links to patches:

Framework development / Re: [Patch] Fixes for the test build
« on: April 11, 2011, 10:40:11 am »
What about the patch for the compile fixes?  Can it be committed?

Framework development / Re: OS X Snow Leopard - build issues
« on: April 05, 2011, 10:22:56 pm »
I managed to get the build working on snow leopord.  The problems are many fold.  First, scons from macports depends on python 2.6, which fink insists on compiling for itself..  Also, the fink dependencies for the python packages (like yaml), are installed for macports python 2.6, NOT the system 2.6.

Furthermore, the fink python 2.6 builds as a framework, but it's broken.  Consequently, when you build fife, it builds against the system python.  Furthermore, the system python is installed as "python" but the macports python 2.6 is installed as "python2.6"

So to fix the problem you have do one of:

Fix the python2.6 framework so that fife can link against it.  Then fix all references to "python" in the tops of scripts to be "python2.6" (or symlink python2.6 as python, probably in ~/bin or something).


Install the extra python modules somewhere and add that to your PYTHONLIBDIR environment variable, and use the system python to link.  A complication here is that the mac build of fife explictly tries to use the headers from macports python 2.6, so you'll have to fix the darwin build of fife if you go down this route.

I opted for (1).

After installing the macport dependencies:

$ cd /opt/local/Library/Frameworks/Python.framework
$ cd Versions
$ ln -s 2.6 Current
$ cd ..
$ ln -s Versions/Current/Python Python
$ ln -s Versions/Current/Headers Headers
$ ln -s Versions/Current/Resources Resources

Then clean and rebuild fife.  If you've done this correctly, you should be able to use otool to see if it's linking against macports python.

$ otool -L <fife-dir>/build/release/

Examine the output and make sure it's linking against the macports python and NOT the system python.  If it is, you should be able to go to your unknown-horizons directory and type:

$ python2.6

You must explictly call python2.6 otherwise the #! in wlll call into "python" which is the system python and doesn't have the modules installed.

*an annoyance with this whole process is that macports will install both python 2.6 and python 2.7.  This means that the python framework in /opt/local will contain both a python 2.6 and python 2.7 dir.  However several of the dependencies available in fink are /only/ available as python  2.6 builds, so I made "2.6" the "Current" version in the framework to ensure that everything links against the version that appears to have better support.

Framework development / [Patch] Fixes for the test build
« on: April 04, 2011, 09:41:25 pm »
Attached is a patch to fix the test build on head.  All it does it make it so the tests compile:  they still don't pass (at least they don't pass on mac os x).

Also, I've noticed a bunch of build issues on Mac OS X.  Anyone mind if I fix those?

Pages: [1]