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.
