This patch changes openvdb from a static to a dynamic library.
this is in preparation for enabling pyopenvdb at some point
in the future.
Differential Revision: https://developer.blender.org/D8282
Reviewed by: brecht
This this adds the option of building boost::python
in the libs builder, in preparation for future
dependencies that require it (ie pyopenvdb)
disabled by default, can be enabled with the
`WITH_BOOST_PYTHON` cmake option.
Differential Revision: https://developer.blender.org/D8212
Reviewed by: brecht
Required for the new boolean code, disabled by default
until all platforms have landed the libs and the boolean
code actually lands in master.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8384
Enabling all `make deps` dependencies with the exception of Embree and OIDN.
After that, Blender can be compiled on an Apple Silicon Mac just like on any
Intel based Mac. There are still compiler warnings that need to be
investigated and there are probably a couple of bug still to be discovered
and to be fixed.
Most patches to the dependencies are simple and are about disabling SSE and
setting the proper architecture to compiile for. Notable exception is Python,
where I back ported a yet to be accepted PR for upstream Python:
https://github.com/python/cpython/pull/21249
Cross compiling or buliding a Universal Binary is not supported yet.
The minimum macOS target version for x86_64 remains at 10.13, the target
for arm64 is 11.00.
Differential Revision: https://developer.blender.org/D8236
There were two issues.
First is related on ISPC's CMake configuration forcing C and C++
compilers to be clang and clang++. This goes against of desired
behavior when we use our own compiled clang compilers.
The second issue was related on linker failure: CLang libraries
are linked statically, and they need some of C++ 11 STL symbols
which are coming from libstdc++.
Differential Revision: https://developer.blender.org/D8258
C++17 does not work on 10.12, and Apple extended support ended for 10.12 in
October 2019.
Maniphest Tasks: T76783, T76184
Differential Revision: https://developer.blender.org/D8179
The upstream version of nasm does not put version information to the
generated object files, which makes linker to show the following
warning:
building for macOS, but linking in object file
Using own patched version of nasm which puts required information to
the object file, making linker happy.
The plan is to either streamline the patch and provide it to the
upstream, or, it that takes too long, get an independent fix from the
upstream.
We don't need it and it was optionally enabled, causing Blender to fail
to link on certain configuration (when Brotli is installed via Homebrew
for example).
The configuration was confused about gettext installed via Homebrew
and isysroot passed to Python's compilation but not to test programs.
After this change `import gettext` still works, but it is unclear how
to test it further,
Differential Revision: https://developer.blender.org/D8231
Set of fixes which had to be made in order to have dependencies built
on own laptop:
- Require bison as a dependent software. It is required by ISPC.
On macOS it is required to be installed via Homebrew. This is because
Bison from Xcode toolchain is too old.
- Made sure Boost is compiled using clang.
Without this gcc was used, and some unsupported command line argument
was passed to it.
- Modify OGG in a way which does in fact pull fixed sized types.
They are defined in stdint.h.
Without this fix FFmpeg will not detect presence of OGG because the
test program fails to compile.
- Force disable zstd compression and make wepb optional for the TIFF
library. Without this TIFF might pick up development libraries from
Homebrew.
Differential Revision: https://developer.blender.org/D8221
When there is no system python OSL will fail to build the documentation.
Given we don't ship the documentation, this is safe to disable.
Originally part of D8123
When doing a release build the TBB debug libs are not
set which was causing an error during the configure
phase of USD, so always set them even if not used.
This requires ISPC for building OpenImageDenoise, so that is now added as
a dependency as well. Blender itself does not need ISPC for building so it
is not included as part of the precompiled libraries.
Differential Revision: https://developer.blender.org/D7641
The Blender USD code didn't have to change for this upgrade. Pixar's USD
did include a change that we had in the patch, so that's been removed
from our patch now. Some of the USD code that we patched changed as
well.
The old URL did have a Git commit hash in it, but apparently the server
was ignoring it and only used the `master` that was also mentioned in the
URL. As a result, every new download would get the latest version from
the `master` branch, invalidating the SHA256 checksum.
I replaced `master` with the actual commit hash. This should make the
situation stable.
No functional changes.
embree marks a few of its functions with a dll_export macro
forcibly exporting these symbols from whatever binary links
them. Given we link embree statically and we do not want these
exports in the blender binary, the macro needs to be a no-op.
This updates python to the latest patch level available for 3.7
also updates some of the packages we rely on:
idna 2.9
urllib3 1.25.9
cerifi 2020.4.5.2
requests 2.23.0
numpy 1.17.5
This upgrade required a few changes:
- Some parts of our patch are no longer necessary, as the USD library
now includes those changes.
- The rest of the patch needed adjustment as the `pxr/base/lib/*`
directories in USD's source code have moved to `pxr/base/*`.
- Updated library names on Windows -- thanks @LazyDodo.
Note that this does not enable the USD Python API for inclusion in
Blender. It just aims at being an as-simple-as-possible version upgrade
of the USD library.
This is the cluster of OIIO and friends , since they are all kinda tangled best to deal with this as a single unit
OIIO 2.1.15.0
png 1.6.37
jpeg 2.0.4
opencolorio 1.1.1
tiff 4.1.0
OSL 1.10.10
pugixml 1.10
openjpeg 2.3.1
Differential Revision: https://developer.blender.org/D7727
Reviewed by: brecht
This diff updates:
FFmpeg : 4.3.2
libogg : 1.3.4
flac : 1.3.3
vpx : 1.8.2
xvid : 1.3.7
x264 : 33f9e1474613f59392be5ab6a7e7abf60fa63622
x264 seemingly has given up on even providing snapshots
and has been updated to the latest hash available at
this time.
faad has been removed since ffmpeg has not supported
it since 2010.
For a more detailed description of the issue see the commit
message for rB497cd3d7dd6e497be484eb78a8ddb23f53b20343
This change moves fftw to a shared library and reverts the bandaid
we did for 2.83.
Unsure what it is that upsets it so much, but when linking
both sndfile and fftw dynamically, the linker gets confused
and thinks that fftw is importing sf_close from the blender
binary (which makes *NO* sense) leading to a start-up error.
Generating the import library from the .def file using the
ms lib tool creates an import library that works fine.
The msvc linker had been warning about libcmt being dragged
in for a bit, finally tracked the issue down to the deps of
jpeg and pthreads which both ignored our cflags.
this diff changes them both to use the dynamic crt rather
than the static one so they'll be in line with all our
other libraries.
Static tbb has always been frowned upon [1] sofar it has worked for us but
given our reliance on tbb is about to increase (D7475), I'd like to move the library
to more supported configuration. Which means moving it to be a dynamic library
The libs part of this change is in rBL62416
Reviewed By: Brecht
Differential Revision: https://developer.blender.org/D7570
The OpenXR-SDK contains utilities for using the OpenXR standard
(https://www.khronos.org/openxr/). Namely C-headers and a so called
"loader" to manage runtime linking to OpenXR platforms ("runtimes")
installed on the user's system.
The WITH_XR_OPENXR build option is disabled by default for now, as there
is no code using it yet. On macOS it will remain disabled for now, it's
untested and there's no OpenXR runtime in sight for it.
Some points on the OpenXR-SDK dependency:
* The repository is located at
https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* Notes on updating the dependency:
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency
* It contains a bunch of generated files, for which the sources are in a
separate repository
(https://github.com/KhronosGroup/OpenXR-SDK-Source).
* We could use that other repo by default, but I'd rather go with the
simpler solution and allow people to opt in if they want advanced dev
features.
* We currently use the OpenXR loader lib from it and the headers.
* To use the injected OpenXR API-layers from the SDK (e.g. API
validation layers), the SDK needs to be compiled from this other
repository.
The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR
with OpenEXR.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Differential Revision: https://developer.blender.org/D6188
Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray
Molenkamp
