Issue with previous code was that branch selected was applied to all repositories.
To be able to control branch on a per-repo basis, we need to use codebases instead.
This commit only enables branch (master/testbuild) and revision selection for master,
we probably do not need this for submodules currently (easy to enable anyway).
Note: tested on local buildbot setup, for linux only (up to build step, have no build env).
This is a temporary solution in order to get at least
rest of the blender begin up-to-date on the buildbot.
To be able to compile cubins again we need to switch
OSX builder machine to OSX 10.8 and CUDA toolkit 6,
which might take some time, unfortunately.
This also updates the configurations to build kernels for compute capability
5.0 cards, when using and older CUDA toolkit version this will be skipped.
Also includes tweaks to improve performance with this version:
* Increase max registers on sm_30, sm_35 and sm_50
* No longer use texture storage on sm_30
Consider this configuration final-1 for the migration,
Linux and OSX slaves seems to be fine, Windows slave
would need some changes from the slave side.
This means that if you have WITH_BF_QUICKTIME or WITH_CODEC_QUICKTIME enabled,
it will always use QTKit.
The old backend was only used on 32 bit OS X builds, now 32 and 64 bit builds will
give consistent input/output. On Windows or Linux quicktime isn't being used.
Add numpy installation to blender player configuration,
this is so because player is building first and it installs
python, which prevented numpy installation from blender
configuration.
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.
Make it so install directory is being nicely
cleaned before next build, which makes it
automatically removing all old files from
previous installations.
Otherwise linux buildbot fails dramatically.
That revision also leads to msvc runtime libs being removed, will fix this
in separate commit.
Take more respect for such creepy as linux and windows platforms, they're not so bad!
* Deprecate computing capability 1.3 (sm_13)
This commit disables auto build of sm_13 CUDA platform, which means that starting with Blender 2.67, we don't support sm_13 devices anymore. It has become difficult to support that and it was already feature incomplete (no render-passes, AO, Multi Closure etc).
It's still possible to manually enable sm_13 for own tests, but building might break in the future.
Crosscompiling of cubins doesn't work on linux with toolkit 4.2,
so use native toolkit for now. Disabled sm_13 for 32bit platform
for now.
Would keep cudakernels build target for a while. It doesn't hurt
being in the code and it could be helpful again once we'll switch
to toolkit 5.x where crosscompilation works fine.
Some further tweaks could probably be needed still, let's see how
building goes on buildbot now :)
Issue was caused by how CUDA devices availability done in Cycles.
Basically, if there's no WITH_CUDA_BINARIES buildtime, nvcc becomes
mandatory dependency.
Since kernels are building in separate target now, this logic broke
a bit.
Perhaps condition in util_cuda shall be changed to be a bit smarter,
but for now just work-around by enabling CUDA binaries when building
Cycles. Made it empty arch list to be sure no kernels will try to
re-compile after cudakernels target is done.
- BF_BITNESS should be passed as a command line argument
- Made it so CUDA binaries and OSL compiled scripts would
be installed regardless WITH_BF_PYTHON (which seems to
be quite obvious)
- Disable overwrite install, so CUDA kernels installed by
it's build target will be preserved when building blender
itself.
* Use rsync upload for Mac slave, rather than uploading entire file. This could
be enabled for more slaves, should make more frequent builds possible.
* Split Mac into 10.6 and 10.5 builds.
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.
- Force libsamplerate linking statically
- Remove global compiler flags for sse2 and sse.
Tests of release builds didn't show big difference in time of
tracking using SAD algorithm or time of solving,
so this shouldn't introduce big slowdown.
- use cores+1 threads
- do not clean build directories
- separate build directories for blender and blenderplayer
This should make compilation much faster and buildbot rebuild tag could
happen more often
Force link to zlib for all platforms/tragets to be sure there'll
be no gzopen64 symbol undefined (it was in some dependend library, so
blenderplayer wasn't working in fedora 13 32bit)
- Remove packed to buildbot_archive.zip archive file to keep scons install
directory as clean as possible (if i understood correct, this file isn't
actually needed in the future, so we could remove it just after packing rather
than cleaning install directory before packing as it's done for cmake)
- No need in scripts installation for linux slaves when preparing archive
- Use the same config as we're using for release builds
- Added stipping (maybe it should be generalized)
- Not software gl packing, bot would be easy to add
Note, that you should have special environment to create
proper linux builts (which would work for everybody)