This is a much simpler fix to that libyaml-cpp mess, since doing it that way we get our static own
libyaml-cpp... And this should work for all platforms (realized libymal-cpp-ver option was only
implemented for deb-like distro, since it was the first place where issue showed up :/ ).
Newest clang would use 'cfe-' prefix instead of 'clang-' one - don’t ask me why...
Had to make a wrapper around wget, that:
* Accepts an array of URLs as first parameter;
* Errors and exits when wget fails for some reason (was silent before).
Issue reported in T40871 by simonrepp (Simon Repp), thanks.
Issue is, looks like Debian testing's graphic backend now uses LLVM-3.4,
which conflicts with 3.3 in Blender and makes it crash.
So add support to handle 3.4, by both allowing to force a specific version for some libs,
and switching back to head of official repo for OSL.
This is a resubmission of the original patch from D255. Sorry, I didn’t understand that subsequent patches added to a diff are considered to //override// previous ones, rather than add to them.
Basically the comment for commit rB554eca1c288e has been applied to the wrong patch.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D359
The file ##build_files/build_environment/install_deps.sh## contains the following line:
THREADS=`cat /proc/cpuinfo | grep processor | wc -l`
The command within the backticks is a [[ http://catb.org/jargon/html/U/UUOC.html | Useless Use Of Cat ]].
A more compact way of writing the same thing (saving two subprocesses) is
THREADS=`grep -c processor /proc/cpuinfo`
or (using POSIX-preferred command-substitution parentheses instead of backticks)
THREADS=$(grep -c processor /proc/cpuinfo)
But the most compact, and least Linux-specific, way is to use the ##nproc##(1) command from the [[ http://www.gnu.org/software/coreutils/manual/html_node/nproc-invocation.html | GNU coreutils package ]]:
THREADS=$(nproc)
Reviewers: sergey, mont29
Reviewed by: mont29
Differential Revision: https://developer.blender.org/D255
Ubuntu hack: add a --libyaml-cpp-ver parameter, to try to force installing a given version of this lib...
(only for DEB-like distro, I dare hope Trusty (!) is the only affected distro.
Not happy at all to have such things here, this is actually an Ubuntu bug, but will have to live with it I guess.
So, after hours of wild hunt, I think both CMake and Scons builds work again.
There were several small issues hiding here and there, esp. for scons.
*WARNING* the --all-static is currently officially broken (it was already quite useless in fact).
I’m seriously considering dropping it completely, having a script compiling a chain
of static libs in a complete working way for *two* different build systems is just
too much work (static libs are *really* a nightmare at link time).
Builders who want to generate static Blender (to share it e.g.) will have to handle things by hand for now.
Main other points changed:
* Many changes to generated settings for scons (notably, I had to hack around the fact that the short ld -l
option does not work with lib names like 'Iex-2_1', which is not that surprising).
* Opencollada remains the only lib built statically (can't get it to build dyn currently).
* All other libs, even ILMBase ones, are now fully dynamic ones.
* Some general cleanup with CMake definitions of built libs.
* Git-libs do not clone again and again the repo anymore!
Note that I also updated OpenEXR to 2.1.0 (and updated our CMake openexr module as well).
Users will have to update their build settings as told by the script (also in BUILD_NOTES.txt generated file)!
Note I removed all ugly patches from this script, we are currently using custom git repo for OpenEXR/OIIO/OSL,
hopefully we will soon be able to use vanillia code from official repos!
I’m not close to understand why this has worked fine until today... :/
Only tested with Debian, but I would not expect any issue with Fedora/Suse/Arch, this is a quite simple change!
