MussaGL Build Info

General Requirements

You will need to make sure the following are all installed in order to build from source.

• ​CMake >= v2.4
• Qt4.1.x - ​Linux | ​Mac OS X | ​Windows >= 4.1.2
• ​Boost C++ Libraries >= 1.33.1
• ​Python
• Mussagl Source (See download section)

Windows XP Requirements

See the Building MussaGL on Windows page for more information.

OS X Universal Build Dependencies

Mussa now builds as a universal binary on OS X, this means you'll need to follow the instructions on OS X Universal Dependencies

Qt4

Qt4 is fairly easy to install.

configure
make 
make install

usually works. The biggest problem I've seen is that one might need to tell Qt to use internal versions of some graphics libraries if one is intending to redistribute the binary being built.

Boost

NOTE: The following directions are for Boost 1.33.1... We are currently working on migrating to Boost 1.34 w/ Python 2.5, which looks like it will take bit of effort to get it to work properly. This documentation will be updated once we have it working.

Boost is more challenging to build. First one needs to obtain ​BJam for ones platform. Then if one has limited disk space one might need to limit which libraries that are built. Currently we're using: program_options, test, python, spirit, filesystem and some of the string processing algorithms.

For windows users there's a copy of a build tree at ​http://woldlab.caltech.edu/~diane/proj/win32-boost-mingw-build.tar.bz2

Example command(s) for building boost from source (building only parts used by Mussa):

Win32 w/ Mingw

bjam "-sTOOLS=mingw" --with-python-version=2.4 --with-python --with-program_options --with-filesystem --with-serialization --with-test install

Win32 w/ Visual Studio 2005 (Although this compiles successfully, I have not been able to build Mussa using Visual Studio and do not need to due to Mingw. -king)

bjam "-sTOOLS=vc-8_0" --with-python-version=2.4 --with-python --with-program_options --with-filesystem --with-serialization --with-test install

Debian (Why build from source when you have Debian packages?):

apt-get install libboost-python-dev libboost-python1.33.1 libboost-program-options-dev libboost-program-options1.33.1 libboost-serialization-dev libboost-test-dev libboost-test1.33.1

CMake

Note: Requires cmake version >= 2.4

To check your current version, type:

cmake --version

If you don't have CMake binaries are available for download at ​http://cmake.org/HTML/Download.html

CMake takes the place of the GNU autotools effectively replacing the "configure" step (and the automake and autoconf steps as well). The big advantage is that since CMake implements its own macro language one doesn't need to know portable bash scripting and m4 to write new build tests, like one does when using autotools. This makes building on windows dramatically easier.

Building Mussa

Once one has the dependencies one can actually build mussa.

First checkout mussa using ​darcs (Hopefully soon there will be source distributions as well as binary distributions).

bzr branch http://woldlab.caltech.edu/bzr/mussa mussa
cd mussa
mkdir build
cd build
cmake ..
make

To run the unittests from with in the build directory type

make test

or

ctest 

OS X & Multiple Python Installations

If you're building on OS X and have several different versions of python installed you might want to pick which python to link against. To do so, you'll need to use ccmake to edit 4 CMake python variables.

For instance if you want to link against the version of python that ships with OS X, you need to use the following settings.

PYTHON_DEBUG_LIBRARY = -F/System/Library/Frameworks -framework Python
PYTHON_LIBRARY = -F/System/Library/Frameworks -framework Python
PYTHON_EXECUTABLE = /usr/bin/python2.3
PYTHON_INCLUDE = /usr/include/python2.3

-F needs to be set to which the base path of whatever framework you want to force to be used, and it needs to precede the -framework you want to force.

CMake Troubleshooting

CMake could not find a dependency.

CMake includes a program

ccmake

that allows one to view and edit the CMake configuration variables. I'm still a bit new at properly creating a CMake configuration so it's very likely that one will need to use the "advanced" view which shows all of the configuration variable in order to find what is NOT_DEFINED. (Or was it "NOT_FOUND")?

To see all of the build commands run make like this:

make VERBOSE=1

To see the output of the unittests

ctest -VV