Installation » History » Revision 44
« Previous |
Revision 44/175
(diff)
| Next »
Tony Ciavarella, 03/12/2013 08:55 PM
Installation¶
Obtaining the Source Code¶
Release Tarballs¶
Release source tarballs are available on the Files page. This is what you want if you are looking for stability and something ready for production use. You'll probably want to use the most recent version found on that page.
SCM¶
The Disorder source code is hosted in a Bazaar repository. This is what you want if you are looking for the very latest bleeding edge of the code for contributing to Disorder or whatever other reason you may have.
Read the Bazaar Documentation if you aren't familiar with that and you want to go this route.
To get a lightweight checkout of the latest version without all the history (not suitable for Disorder development):
bzr co --lightweight bzr://bzr.squalllinesoftware.com/disorder
To clone the repository including the full history (suitable for Disorder development):
bzr branch bzr://bzr.squalllinesoftware.com/disorder
Prerequisites¶
Given the assumption that a somewhat sane build environment for C++ already exists on the build machine, the following third party things are required to build Disorder:- Boost >= 1.49.0
- Eigen >= 3.0.5
- C++ version of the SEDRIS SRM >= 4.4.0 (optional but you will need some kind of sophisticated geospatial library)
- A Python interpreter (needed to use the waf build system)
Build and install these things in accordance with the instructions for your operating system provided by each vendor. Some hints for certain platforms follow.
Debian Linux and Derivatives¶
Debian 6.x (Squeeze)¶
The binary packages for Boost and Eigen in the package system are way too old. You'll have to download the source for them and build Boost yourself.
Debian >= 7.x (Wheezy)¶
All the dependencies are available via the package system. To install the Boost and Eigen build dependencies on Debian and maybe other derivatives:
sudo apt-get install libboost-dev libboost-system-dev libboost-thread-dev libboost-date-time-dev libeigen3-dev
If you don't already have python, this will get the required bits of that:
sudo apt-get install python
Sabayon Linux¶
To install boost via the entropy package system:
sudo equo install boost
As of 2/22/2013, the Eigen verison in entropy is a bit outdated (3.0.6). You can use it, but you probably should download the latest version from Eigen which doesn't require any compilation. Just extract the content of the archive somewhere and remember to tell Disorder where to find it with --eigen-root=<put actual path to eigen root here> during the configuration step.
If you don't already have python, this will get the required bits of that:
sudo equo install python
Configuration¶
If everything is setup properly, this step will be a breeze, but it is important to resolve any errors produced by the configuration step prior to attempting to compile Disorder.
Linux¶
From inside the root of the Disorder tree do this in your favorite terminal emulator:
./waf configure --sedris-srm-root=<put the path to the SEDRIS SRM root here>
For example, if your SEDRIS SRM is in /opt/sedris/srm:
./waf configure --sedris-srm-root=/opt/sedris/srm
That command will take several seconds and print a bunch of hopefully green stuff. The output should end up looking something like this:
Setting top to : /opt/disorder Setting out to : /opt/disorder/bin Checking for 'g++' (c++ compiler) : /usr/bin/g++ Checking for program doxygen : /usr/bin/doxygen Checking for program tar : /bin/tar Checking boost ABI tag : Checking boost includes : 1_49 Checking boost libs : ok Checking for boost linkage : ok Checking for header boost/asio.hpp : yes Checking for header boost/bind.hpp : yes Checking for header boost/date_time.hpp : yes Checking for header boost/detail/endian.hpp : yes Checking for header boost/format.hpp : yes Checking for header boost/function.hpp : yes Checking for header boost/functional/factory.hpp : yes Checking for header boost/ptr_container/ptr_vector.hpp : yes Checking for header boost/scoped_ptr.hpp : yes Checking for header boost/static_assert.hpp : yes Checking for header boost/thread.hpp : yes Checking for program pkg-config : /usr/bin/pkg-config Checking for 'eigen3' : yes Checking for header Eigen/Dense : yes Checking for SEDRIS SRM : /opt/sedris/srm Checking for SEDRIS SRM include directory : /opt/sedris/srm/src/include Checking for SEDRIS SRM library directory : /opt/sedris/srm/lib/linux-3.1.0-1-amd64-i386-gnu-/OPT SEDRIS SRM library : /opt/sedris/srm/lib/linux-3.1.0-1-amd64-i386-gnu-/OPT/libsrm.so Checking for header srf_all.h : yes 'configure' finished successfully (25.518s)
If you get an error instead of that last line saying that 'configure' finished successfully, you must fix whatever is making it unhappy and try again.
Clang++¶
To use the Clang C++ compiler instead of GCC, assuming clang++ is installed on the build system:
CXX=<put the path to clang++ here> ./waf configure --sedris-srm-root=<put the path to the SEDRIS SRM root here>
For example:
CXX=/usr/bin/clang++ ./waf configure --sedris-srm-root=/opt/sedris/srm
Windows¶
On windows, your $PATH environment variable needs to include the path to the Python interpreter.
The easiest way to configure Disorder on Windows is to use a modified version of the provided batch file to tell Disorder where your prerequisites live. Copy the template from tools/windows/configure.bat
to the root of the Disorder tree.
This file contains some variables near the middle that must be set according to your system configuration. An example is provided in the template for guidance.
Once you are finished editing configure.bat, it's time to execute it. From the command line:
configure.bat
If everything is successful, you should get something that looks like this:
C:\oss\disorder>python waf configure --boost-includes=c:\oss\boost_1_48_0 --boost-libs=c:\oss\boost_1_48_0\stage\lib --boost-mt --boost-static --eigen-root=c:\oss\eigen-3.0.4 --sedris-srm-root=c:\oss\sedris\srm --sedris-srm-static Setting top to : C:\oss\disorder Setting out to : C:\oss\disorder\bin Checking for 'msvc' (c++ compiler) : c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe Checking for program doxygen : not found Checking for Eigen library : c:\oss\eigen-3.0.4 Checking for header Eigen/Dense : yes Checking for SEDRIS SRM : c:\oss\sedris\srm Checking for SEDRIS SRM include directory : c:\oss\sedris\srm\src\include Checking for SEDRIS SRM library directory : c:\oss\sedris\srm\lib\[Debug/Release] Checking for header srf_all.h : yes Configuring boost libraries : debug variant Checking boost ABI tag : gd Checking boost includes : 1_48 Checking boost libs : ok Checking for boost linkage : ok Checking for header boost/asio.hpp : yes Checking for header boost/bind.hpp : yes Checking for header boost/date_time.hpp : yes Checking for header boost/detail/endian.hpp : yes Checking for header boost/format.hpp : yes Checking for header boost/function.hpp : yes Checking for header boost/functional/factory.hpp : yes Checking for header boost/ptr_container/ptr_vector.hpp : yes Checking for header boost/scoped_ptr.hpp : yes Checking for header boost/static_assert.hpp : yes Checking for header boost/thread.hpp : yes Configuring boost libraries : optimized variant Checking boost ABI tag : Checking boost includes : 1_48 Checking boost libs : ok Checking for boost linkage : ok Checking for header boost/asio.hpp : yes Checking for header boost/bind.hpp : yes Checking for header boost/date_time.hpp : yes Checking for header boost/detail/endian.hpp : yes Checking for header boost/format.hpp : yes Checking for header boost/function.hpp : yes Checking for header boost/functional/factory.hpp : yes Checking for header boost/ptr_container/ptr_vector.hpp : yes Checking for header boost/scoped_ptr.hpp : yes Checking for header boost/static_assert.hpp : yes Checking for header boost/thread.hpp : yes 'configure' finished successfully (31.262s)
If you don't see that last line that says 'configure' finished successfully
, then something is screwed up and it needs to be fixed. Fix it and try again.
Compiling¶
The basic strategy for building Disorder is to invoke the waf build system with the desired build variant.
Disorder has two build variants:- debug: produces a library that contains debugging symbols and disables most compiler optimizations
- optimized: produces a library stripped of debugging symbols and enables compiler optimizations for performance
It might be reasonable to use the debug
variant in a development environment and the optimized
variant in a production environment.
The debug
variant is produced by the build_debug
build target and the optimized
variant is produced by the build_optimized
build target.
The results of the build are put in the bin
subdirectory under the name of the variant.
Both variants can coexist peacefully in the tree at the same time.
Linux¶
On Linux, to build the Disorder debug
variant:
./waf build_debug
Windows¶
On Windows, the waf script is invoked indirectly. To build the optimized
variant:
python.exe waf build_optimized
Ensuring Build Correctness¶
Due to the complexity of varied compilers and build configurations, it is imperative that you preform the necessary testing on your build to ensure that it performs correctly.
Don't fret. It's easy and is well worth the time it takes for the peace of mind you gain. Just tell waf to test_all_<variant> like this for the optimized
variant:
./waf test_all_optimized
That should result in something this:
Waf: Entering directory `/opt/disorder/bin/optimized' [PASS]: all 1 tests passed! [PASS]: all 1192 tests passed! [PASS]: all 75091 tests passed! [PASS]: all 12 tests passed! [PASS]: all 85 tests passed! [PASS]: all 7659 tests passed! [PASS]: all 46 tests passed! [PASS]: all 536 tests passed! Waf: Leaving directory `/opt/disorder/bin/optimized' 'test_all_optimized' finished successfully (1.184s)
If you see
Something failed! That's not good. This build cannot be trusted until the damn thing is fixed.
in red at the bottom instead of a green "finished successfully" message, you need to file a bug report and/or fix it yourself and send in a patch. Under no circumstances should you attempt to use a build that fails the test suite. A test failure means disorder isn't working as expected for some reason and that reason needs to be resolved for your simulation to function properly.
Building Against the Disorder Library¶
Compiling¶
In order to compile your goodness against the Disorder library, you'll need to have the header files from the src
directory in the Disorder tree and Eigen's include directory in your compiler's include path. You do not need anything from SEDRIS SRM in your include path.
Linking¶
Just link your program against Disorder's static library that can be found in the bin/<build variant>
directory.
Updated by Tony Ciavarella almost 12 years ago · 175 revisions