| Age | Commit message (Collapse) | Author |
|---|
|
Root of the issue is an (hidden!) parameter in ILMBase cmake options, that
is enabled by default, and force the generation of those ugly lib names
(Imf_2_2.so & co). Why why why enable such thing by default?
Anyway, it should be simpler to build again even on linuxes having the openexr -dev
package installed.
Also, cleaned up a bit things, now we can switch between repo and plain release archive
building from a single place for each lib, instead of commentting/uncommenting everything
each time (for libs where we have some git repo set up for some reason).
|
|
|
|
|
|
|
|
Reported by Jefferson Rausseo through mail, thanks.
|
|
|
|
Reported through mail by Jefferson Rausseo, thanks!
|
|
Reported by Thomas (DingTo) over IRC, thanks.
|
|
Still defaults to current dir!
|
|
check.
Patch D742, by oweissbarth (Oliver Weissbarth), thanks!
|
|
Btw, if someone can explain me why OPENEXR_FORCE_REBUILD does not work like
all other force options... :/
|
|
|
|
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 :/ ).
|
|
Note: had to swicth back to own repo for osl as well, ILM guys seem unable to handle
CMake build system properly!
|
|
Patch D633 by simonrepp (Simon Repp), thx.
|
|
Patch by simonrepp (Simon Repp), thanks!
|
|
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.
|
|
|
|
Most cases should be handled OK now (not all though, would make script way too much tricky -
bash is a hell of a messy language :/).
|
|
might help in some cases...
|
|
llvm-config does not report it as link arg as it should
(see http://stackoverflow.com/questions/21477407/llvm-3-5-fails-to-link).
|
|
Should always use a fixed rev in git repos!
Also done some other cleanup/fixes.
|
|
|
|
|
|
|
|
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.
|
|
Update warning message!
|
|
disabling usage of sudo!
Note in this case, script becomes more or less useless, just spit out names of packages to install...
Requested by Dalai Felinto over IRC.
|
|
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
|
|
colormanagement/config.ocio
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.
|
|
modern linuxes!
|
|
|
|
OIIO/OCIO is not needed when you use default path, but mandatory otherwise, simpler to always give them).
Spotted by dingto on IRC, thanks!
|
|
|
|
OIIO/OSL source).
|
|
|
|
messages!
|
|
|
|
(always-installed packages), looks like they are needed...
|
|
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 *really* have to go back over all our patches in this script and try to port them back in respective projects!
|
|
|
|
correct values for ffmpeg libraries (at least for static builds).
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!
|
|
|
|
ldconfig immediately after lib compile (looks like OSL compile process needs boost libs...).
|
|
Also switch to python3.3.2
|
