-
Notifications
You must be signed in to change notification settings - Fork 0
Building tips
The offical Blender build manual is your friend. However, read it a few times first, and then follow the steps meticulously (don't ask me how I know this). One particular problem I had that you might want to watch out for is that I arranged the sources, libraries, and build outputs into directories that made more intuitive sense to me. Don't do this - there are relative paths in some places that can prevent libraries from being found, follow the guide exactly.
On Windows, there are a large number of pre-built libraries the guide instructs you to fetch using SVN. I don't know how many are really required, but be warned there are ~6GB of them. I'm using the 32-bit versions of these libraries and as such I've been building Blender in 32-bit also. Originally this was because Visual Studio Express doesn't (natively) build C/C++ in 64 bit, however Microsoft now makes a Community edition available for free, which contains all the features of the Professional edition, with some licensing differences.
I also had issues which I wasn't able to fully resolve when building against the libjack and OpenCOLLADA libraries. I got a build working by choosing cmake build configuration options that didn't touch them (see below).
Finally, I installed the nVidia CUDA SDK as instructed in the guide. I'm not sure how necessary this is (my card is ATI). You might get away without this step, no promises.
#With cmake and Visual Studio 2013 I found this link quite helpful. Cmake can be described as "make for makefiles". Whereas make and makefiles describe how to build the target application, cmake is one level higher. Cmakefiels describe how to create a makefile for building with; or more interestingly, project files for various IDEs (Visual Studio, Eclipse, and many more). Given the size and complexity of a project like Blender, I probably would't manage without having a tool manage the building for me.
The cmake file contains a number of variables you can set to customise what gets built. I turned a few of these off as I had trouble with certain pre-built libraries (see above).
Once you've configured and generated with cmake, you will end up with a .sln file that can be opened in Visual Studio.
When building in VS, I received two more errors before I was able to get a successful build, documented below:
##module machine type 'x64' conflicts with target machine type 'X86'
This was resolved by right-clicking the 'blender' project in Solution Explorer (not the top-level project), and going to Properties -> Configuration Properties -> Linker -> Command line, and adding to "Additional Options" /MACHINE:X86 /MACHINE:IX86
.
##Sudden termination on startup when calling into Py_Initialize(). Make sure you've first built the INSTALL and BUILD_ALL targets (perhaps not in that order).
Finally, I have a vague recollection that there was one more cmake modification I made (I didn't write it down). I'll leave it here in case anyone having this problem searches for it: CMAKE_CONFIGURATION_TYPES
is set to Debug;Release;MinSizeRel;RelWithDebInfo
##Python API Blender is ultimately written in C. This means the Python scripts that are run call into the C functions to perform their work. Something to understand which is not immediately apparent, is that during the build process, the C code to implement this Python interface is generated from parts of the original C source.
This can be confusing because the code generation process can spit out invalid C, which the compiler will then reject, and you're left scratching your head over errors on some bit of code that you didn't even touch.
rna_something_api.c
(the original C function) becomes rna_something_gen.c
(the one exposed to Python)
#With cmake and Eclipse on Linux Mint ... Haven't got this working myself yet...
#SCons Blender also has files for SCons (aka SConstruct) which is used here for a similar job as cmake. I haven't attempted to get this working.
#Useful tools
- For working with a Git/Mercurial repository, I recommend SourceTree. It's fantastic.
- If you will be edting Python scripts, I find Blender's inbuilt scripts editor quite lacking. I haven't tried these yet, but PyTools for Visual Studio looks very promising.