Operating system specific instructions for creating a blender build from scratch.
Blender has two build system, SCons and CMake. Generally they can both build the same features, it's mostly a matter of personal preference. Besides that you must also choose a compiler to install, and choose if you want to build a 32bit or 64bit Blender.
- Using cmake GUI, ccmake or editing ./../build_<platform>/CMakeCache.txt
- Be sure to generate the build files in a directory other than the source directory, e.g. ./../build/
- Build Files
- CMakeLists.txt throughout the source tree.
- ./../build_<platform>/bin, or the project directory for the given generator (CMake -G <generator>).
- ./user-config.py (configuration file)
- ./build_files/scons/config/<platform>-config.py (for hints and documentation, don't edit these!)
- Build Files
- SConscript throughout the source tree.
- ./../install/<platform>/ by default, configurable with BF_INSTALLDIR=<dir>
Resolving Build Failures
Most building problems are not actually errors in blenders source code, although you can never fully rule out that possibility. Here are common causes for failing to build.
On Windows or OS X we provide dependencies, so before troubleshooting further, make sure you updated your local "lib/" checkout.
Missing dependencies cause two types of compiler errors. No such file errors mean a header (.h) file is missing, while unresolved symbol errors when linking mean a library is missing. This is usually because either a path to the dependency was not set correctly in the build system, the dependency was not installed, or a wrong version of the dependency was used.
Finding out which dependencies are broken may sometimes be difficult. Searching online for the missing filenames or symbols will often give a quick answer. On systems with package managers the headers and libraries are usually in a separate development package, called for example foo-dev or foo-devel.
Some complaints of blender failing to build end up being caused by developers forgetting they have made changes to their code (patches applied or edits when developing).
Before spending too much time investigating an error building, check that your checkout has no local changes. You can stash those away (and restore later if desired) with this command:
While Blender is portable, if you compile on a less common operating-system NetBSD for example, it may need some minor edits to compile. The same goes for compilers, less common version may need some adjustments if no active developers are currently using them.
Unless you want to spend time supporting less common development-environments, normally its best to use the default/standard development tools for your platform.
Reporting Build Problems
- ALWAYS include a full error log, just saying "It failed" with 1-2 lines containing the error isn't very helpful.
- Include what build system you use, SCons/CMake, compiler version, git revision of blender.
This section is for details that maintainers need, but not immediately useful for people building Blender.
Blender uses many different libraries, let's try to keep official supported versions (i.e. those used by official build environments) in sync between all platforms!
Note, details on obtaining libraries are included in each platforms build documentation.
|Boost (optional)||1.51 (???)|
|OCIO (optional)||1.0.9 (???)|
|OSL(optional)||patched 1.5 (aka 1.5.11, see https://github.com/Nazg-Gul/OpenShadingLanguage/tree/blender-fixes)|
|OpenCOLLADA (optional)||No official release, git rev: 18da7f4109a8eafaa290a33f5550501cc4c8bae8 (???)|
|FFMEPG (optional)||2.1.5 (note: 'real' libffmpeg, not the libav fork, though this one should work too)|