Building OpenSG 2.0 (CMake)

Starting with revision r1622 OpenSG 2.0 has switched to use the CMake build system generator (at least version 2.6 is required), see below for notes on the scons based build that we used before.

The OpenSG build does NOT support building in the source tree, however your build directory may be a subdirectory of the OpenSG tree, i.e. this is fine:

#OpenSG sources in ${HOME}/opensg-2.0

cd ${HOME}/opensg-2.0
mkdir build
cd build
cmake ..

The most basic interface is the cmake command line tool, that you can invoke with options of the form: -DVariableName=VariableValue followed by the path to the OpenSG source tree (in the example above it is just ..). Alternatively there is the curses based ccmake and also cmake-gui both let you view and change the values for all variables (you might have to enable the advanced mode to see all of them).

External libraries needed by OpenSG are searched for in standard locations, but if you are not happy with what cmake finds or if the libraries are in unusual locations (or you are on Windows where there is no standard location for many packages), you need to modify the variables used by cmake (either pass -D options on the command line or use one of the gui interfaces). For the boost libraries it is often sufficient to just set BOOST_ROOT to the location where boost is installed.

Some variables of interest (this is by far not an exhaustive list):

Variable Description
CMAKE_INSTALL_PREFIX Location where the OpenSG libraries will be installed
BOOST_ROOT Location where the boost libraries are installed (see below for using custom compiled boost)
COLLADA_ROOT_DIR Location where the collada-dom library is installed
OSGBUILD_* Control which OpenSG libraries are build, ["ON", "OFF"]
OSGCOMPAT_ENABLE Enable some compatibility interfaces to ease porting from OpenSG 1.x
OSGCOMPAT_ENABLE_DEPRECATED Include deprecated interfaces
OSGCOMPAT_ENABLE_DEPRECATED_PROPS Include deprecated Geometry Property names
OSG_DOXY_DOC_TYPE Type of doxygen documentation you want to build, ["User", "Developer", "Trac"]
Assuming you want to use a custom version of boost installed to /opt/boost/usr (i.e. there is /opt/boost/usr/include/boost/version.hpp and /opt/boost/usr/lib64/ and collada-dom libraries in /opt/colladadom/usr. The following command will set up the build to use these libraries, build release libs with debug info (-O2 -g) and set the install prefix to /opt/opensg-2.0/usr:
# OpenSG sources in ${HOME}/opensg-2.0

cd ${HOME}/opensg-2.0
mkdir build
cd build

cmake -DBOOST_ROOT=/opt/boost/usr -DCOLLADA_ROOT_DIR=/opt/colladadom/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/opt/opensg-2.0/usr

For MacOS X users Mickael Cormier posted a short step-by-step HOWTO on our mailing list.

Once the build system is generated you are ready to build the OpenSG libraries:

On Linux
make -jN
make install
where N is the number of parallel processes you want to use
On Windows
Open the OpenSG.sln file that was generated in the build dir and build the ALL_BUILD project.

Building OpenSG 2.0 Support Libs (Windows / CMake)

Follow the instructions in <OpenSG_Root>/Support/ReadMe?.txt


Using Custom Boost build on Windows:

  • Build and stage boost using bjam
  • Symlink (on Vista) or move/copy the staged lib directory into the boost-root dir (i.e. <boost>/lib/boost_filesystem_xx_yy.dll)
  • Symlink (on Vista) or move/copy the include directory into the boost-root dir (i.e. <boost>/include/boost/version.hpp)
  • Point CMake to the boost-directory (pass -DBOOST_ROOT=<boost> to cmake or create a BOOST_ROOT variable of type "FilePath?" with value <boost>)

Using OpenSG 2.0.0

CMake projects

If you are using CMake for your own projects and want to make use of OpenSG libraries, there is a simple FindOpenSG.cmake module in the CMake directory of the OpenSG source tree, typical usage would look like:




# after COMPONENTS pass the OpenSG libraries you need:


# EXE here holds the target being built:


A more complete example can be found in Examples/Simple/CMakeLists.txt.

Other buildsystems

For other buildsystems you can use the osg2-config python script that is generated and installed as part of building the libraries (it's only available after r1669 or for the scons build before r1622) . It works in a way similar to pkg-config or flagpoll in that you call it with some command line arguments that specify what information you are interested in and the tool prints a line with its answer (usually in the form of command line arguments for the compiler/linker). Calling it with the --help option prints an overview of the available command line arguments:

On windows
python osg2-config --help
On 'nix
osg2-config --help

Building OpenSG 2.x scons, not available since r1622, just in case you need an older version

After building

If it looks like elements are missing as you run your programs, especially the scene file and image loaders, this unfortunately is a 'feature' of the microsoft linker. Add OSG_LOAD_LIBS=OSGFileIO;OSGImageFileIO to your environment so that the loader dlls are pulled. Add other libraries if other elements are missing.

As an alternative that does not rely on environment variables, you can insert the following into your application, before calling osgInit();:


    OSG::osgInit(argc, argv);

Building OpenSG 1.X

Note that we have binary distributions, so building from source is not necessary.

Building on Linux

Building on Windows

Building on MacOS X

Last modified 5 years ago Last modified on 11/03/12 00:28:47