This is needed to resolve the real used compiler from the compatibility shim’S or symlinks.
Also set the real CCVERSION as scons CCVERSION would only read the default one, which
is not useful for OSX
Summary:
Old idea with changes since previous release tag
didn't work good enough. In most of the cases tag
was done in a branch hence not actually reachable
from the master branch.
Now change since release is gone, and date of
the latest commit is used instead.
The date is displayed in format YYYY-MM-DD HH:mm
in the splash.
New bpy.app fields:
- build_commit_timestamp is an unix timestamp of
the commit blender was build from.
- build_commit_date is a date of that commit.
- build_commit_time is a time of that commit.
Reviewers: campbellbarton
Differential Revision: http://developer.blender.org/D5
- Use commit number since last annotated tag as a
revision number replacement. It'll eb followed
by 'M' symbol if there're local modification in
the source tree.
- Commit short SHA1 is included. Helps getting
information about commit used to build blender
with much faster.
- If build is not done from master branch, this also
will be noticed in the splash screen.
This commit also replaces revision stored in the
files with git-specific fields (change and hash).
This is kind of breaks compatibility, meaning
files which were saved before this change wouldn't
display any information about which revision they
were saved with. When we'll finally switch to git,
we'll see proper hash and change number since
previous release in the files, for until then
svn version will be used as a change number and
hash will be empty.
Not a huge deal, since this field was only used
by developers to help torubleshooting things and
isn't needed for blender itself.
Some additional tweaks are probably needed :)
Crash was happening on windows platforms only and was caused
by some specifics about how CRT works.
Basically, blender and all of the .dll are compiled with /MT
flag, which means blender.exe and all .dll are using separate
environments. This makes it impossible to pass file descriptors
from blender to other dll, because it becomes invalid in the dll.
And this is exactly what was happening: OIIO was trying to open
movie file with all known plugins and one of them was zlib. And
the way OIIO was using zlib API is opening the file using Boost
and passing a file descriptor to zlib. And since zlib was a
dynamic library this lead to general issues using this descriptor
in zlib code.
Solved by linking to zlib statically. This allows to safely pass
file descriptor to zlib API. Alternative would be to compile all
the stuff with /MD flag, but that's much bigger and less robust
way to fix the issue.
Tested on windows using msvc2008, scons plus cmake both 32 and 64
bit versions. Seems to be working fine.
Further tweaks for mingw and msvc2012 could be needed tho.
Added new build option WITH_JACK_DYNLOAD for CMake and
WITH_BF_JACK_DYNLOAD for SCons, which means there'll be
no build-time linking against libjack and getting symbols
from libjack will happen runtime using dlopen and dlsym
tricks.
Alternative would be to use weak linking, but it'll require
having wrapper for preloading libjack.
This new options are disabled by default and they only
intended to be used on linux. Other platforms shall not
be using this and there shall be no functional changes
on non-linux platforms at all.
Initial support of OSL builds using SCons build system. Only tested on Linux now.
No changes to configuration files themselves -- for now check how it's configured
for linux buildbot (it was already horror to make all this changes and verify them,
changes to linux-config.py could easily be done later).
Currently WITH_BF_STATICOSL and WITH_BF_STATICLLVM are more like rudiments because
linking against oslexec requires special trick with --whole-archive. We woul either
need to find a way dealing with this oslexec less hackish or drop STATICOSL and
STATICLLVM flags. Will keep dropping this flags for until we have "final" build
rules for OSL.
Still can not make 32bit linux rendering with OSL -- blender simply crashes when
starting rendering. So for time being this issues are solving disabled OSL for
32bit build slaves.
Proper implementation for only including the boost locale libs when
WITH_BF_INTERNATIONAL is enabled, so that those of us who do not need/want to
bother with translated ui's can compile. The way it was done before was wrong as
1) the value was always set to true earlier in the config scripts, 2) the base
config scripts run before user config overrides are set
This commit integrates support of OpenColorIO library into build systems.
It also contains C-API for OpenColorIO library which could be used by Blender.
CMake has got find rules familiar to OpenImageIO's one which makes it easier
for build system to find needed libraries and includes. Scons only could use
explicitly defined paths to libraries and includes.
C-API would be compiled and Blender would be linked against C-API and OpenColorIO
but it wouldn't affect on Blender behavior at all.
OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and
setting WITH_BF_OCIO in Scons.
This solves crash when trying to render with missing files on MinGW-w64 cycles. The cause was an OpenEXR exception that went uncaught when trying to check the file's extension through OpenImageIO while building the shader tree. Thus my bug-hunting frustration can end with a happy chord.
Assumes numpy is installed to the BF_PYTHON/site-packages/numpy directory,
could be tweaked further, but this should be enough to setup release
building environment.
Seems blender can't import numpy, but that doesn't seem to be scons issue,
the same happens here with cmake too. Would ask Campbell to help looking
into this.
