CMake builder and install deps changes, precompiled libraries are still to be
committed.
Ref T88438, T88434
Differential Revision: https://developer.blender.org/D11486
This revert went too far, only one line (the minimal version of FFMPEG
for `install_deps.sh` script`) actually needed to be reverted...
Sorry for the noise.
rB847579b42250 updated the TBB build script
which had some unintended consequences for
windows as the directory layout slightly
changed.
This change adjusts the builder to the new
structure, there are no version/functional
changes.
Bump FFmpeg version to 4.4 to fix a problem where it would write the
wrong frame rate. Their old API was deprecated and Blender moved to the
new one in rB8d6264ea12bfac0912c7249f00af2ac8e3409ed1. The new one
produced files with the wrong frame rate, which was fixed in FFmpeg 4.4.
Manifest Task: T88568
Reviewed By: LazyDodo, zeddb
Differential Revision: https://developer.blender.org/D11392
Add a `source_archive_complete` target for `make` that creates a source
archive including the source packages of Blender's dependencies.
This expands `make_source_archive.py` to include files from
`${BUILD_DIR}/source_archive/packages/` as well.
Reviewed By: dfelinto
Maniphest Tasks: T86124
Differential Revision: https://developer.blender.org/D10727
Allow downloading of source packages of Blender's dependencies, so that
it's easier to provide a "full source archive" that contains the blender
source + all dependencies archives. A `make` command for this will be
introduced soon.
This changes the deps builder slightly to be more flexible with the
origin of our source packages.
To support this a new CMake variable has been added called `PACKAGE_DIR`
where all sources archives will be stored.
default: a directory called `packages` in the build folder.
alternative-default: if a directory called `packages` exists in the
blender source folder that will be used. This is to support the "full
source archive" use case.
The download phase have been moved from the build phase to the configure
phase. Configure will download all sources validate the hashes while
downloading.
All `[depname].cmake` files have been changed to take a local
`file://[path_to_local_tarball]` path rather than a remote URI.
A second requirement was that there needed to be an option to grab the
sources from the blender SVN mirror rather than upstream. For this an
option has been added PACKAGE_USE_UPSTREAM_SOURCES (default ON). The
exact location in SVN still needs to be worked out, I tested with my
local webserver and codewise it checks out. The path that is in there
currently will not work (given there is no mirror there yet).
To build this mirror our local package caches can be used.
Reviewed By: lazydodo
Differential Revision: https://developer.blender.org/D10598
Looks like they removed static libs by default in OCIO 2.0, for some
historical reasons `install_deps` was enforcing using only static libs
for this one, now removed it so that Blender buil can use usual so's.
This bumps OSL to 1.11.10.0. OSL Has a new build time
dependency: Clang, and more importantly it expects
clang and llvm to share a library folder, which it
previously for us did not.
This patch changes:
-OSL Update to 1.11.10.0
-refactor the llvm/clang/clang-tools-extra builds into the llvm
build using the llvm-project tarball for building that has all
of the subprojects in it.
-update ispc/openmp builds since clang no longer its own dependency
and they have to depend on the llvm build now.
-Update the windows builder to use the 64 bit host tools since it
ran out of ram linking clang
-Since OSL now needs clang to link successfully a findclang.cmake
has been provided for linux/OSX
Differential Revision: https://developer.blender.org/D10212
Reviewed By: brecht, sebbas, sybren
rBc70eb30240f8b5d5a8f2ac509f0eb585936142b5 added patch to use static
zlib on Linux. But also added flags to use the zlib in LIBDIR for
Python on macOS. That causes some shared libraries (binascii for one)
to link against libz.1.dylib which will not be there on users' systems.
Reuse the said patch for macOS also to avoid rpath issues.
Fix T85648.
Reviewed By: #platform_macos, brecht
Differential Revision: https://developer.blender.org/D10479
This required using a fork of Embree, newer LLVM version, unreleased ISPC
version and sse2neon directly from Git. Hopefully over time all the required
changes end up in official releases. For now we deviate from other platforms.
Based on contributions by Apple and Stefan Werner.
Ref D9527, D8237, T78710
Building NumPy from source with default options of builder
causes it to link against Accelerate framework which is buggy and
raises a warning mentioned in [2].
"RankWarning: Polyfit may be poorly conditioned"
Accelerate is deprecated with NumPy 1.20+.[1]
So either we build OpenBLAS in dependencies also and set appropriate
env variables suggested in [1] while building NumPy for it to find
OpenBLAS. Or download NumPy wheel from pip and never allow pip to
build NumPy from source while installing.
After this change, pip wheels are used for NumPy for macOS with x86_64.
[1] https://numpy.org/doc/stable/user/building.html#lapack
[2] https://github.com/numpy/numpy/issues/15947
Reviewed By: #platform_macos, sebbas
Differential Revision: https://developer.blender.org/D10368
USD version 21.02 includes two of the changes Blender used to patch in,
which have now been removed from `usd.diff`. Unfortunately 21.02
introduces another issue where LZ4 symbols are accidentally exported,
causing linker errors. Fortunately these symbols are only used for
resting, so I added a patch hunk that simply removes their `extern "C"`
declaration.
The LZ4 linker issue has been reported upstream at
https://github.com/PixarAnimationStudios/USD/issues/1447.
Reviewed By: sebbas, mont29
Differential Revision: https://developer.blender.org/D10367
Straight up version bump
Things of note:
They started using API calls only available in windows 8, however given
the Python 3.9 update will forcibly bump us to 8.1+ anyhow this is not
an issue.
Will require some minor tweaks to platform_win32.cmake after adding the
libs to svn which are not included in this diff so this diff can land
without having to have the libs in place yet.
Reviewed By: sebbas, sybren
Differential Revision: https://developer.blender.org/D10349
Straight forward version bump, some of the variables to detect a static
OpenEXR changed and the folder structure seemingly changed a little
requiring updates to the diff
Reviewed By: sebbas, sybren
Differential Revision: https://developer.blender.org/D10340
Version bump + no longer using Boost.
Building Alembic with Boost gave compiler errors, and having one less
inter-dependency is good as well.
Reviewed By: sebbas, sybren
Differential Revision: https://developer.blender.org/D10329
Straight forward version bump.
2020U2 is significantly louder in the deprecated header usage warning
department, we should probably see if we need to act on this: P1949
Differential Revision: https://developer.blender.org/D10359
This resolves build error with Py3.9x, use meson build system
since autoconf/automake are no longer supported.
This adds ninja & meson as dependencies for Linux.
Reviewed By: brecht, sybren
Ref D10282
Ref T84819
Build System
============
This is an API breaking new version, and the updated code only builds with
OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated.
* Tinyxml was replaced with Expat, adding a new dependency.
* Yaml-cpp is now built as a dependency on Unix, as was already done on Windows.
* Removed currently unused LCMS code.
* Pystring remains built as part of OCIO itself, since it has no good build system.
* Linux and macOS check for the OpenColorIO verison, and disable it if too old.
Ref D10270
Processors and Transforms
=========================
CPU processors now need to be created to do CPU processing. These are cached
internally, but the cache lookup is not fast enough to execute per pixel or
texture sample, so for performance these are now also exposed in the C API.
The C API for transforms will no longer be needed afer all changes, so remove
it to simplify the API and fallback implementation.
Ref D10271
Display Transforms
==================
Needs a bit more manual work constructing the transform. LegacyViewingPipeline
could also have been used, but isn't really any simpler and since it's legacy
we better not rely on it.
We moved more logic into the opencolorio module, to simplify the API. There is
no need to wrap a dozen functions just to be able to do this in C rather than C++.
It's also tightly coupled to the GPU shader logic, and so should be in the same
module.
Ref D10271
GPU Display Shader
==================
To avoid baking exposure and gamma into the GLSL shader and requiring slow
recompiles when tweaking, we manually apply them in the shader. This leads
to some logic duplicaton between the CPU and GPU display processor, but it
seems unavoidable.
Caching was also changed. Previously this was done both on the imbuf and
opencolorio module levels. Now it's all done in the opencolorio module by
simply matching color space names. We no longer use cacheIDs from OpenColorIO
since computing them is expensive, and they are unlikely to match now that
more is baked into the shader code.
Shaders can now use multiple 2D textures, 3D textures and uniforms, rather
than a single 3D texture. So allocating and binding those adds some code.
Color space conversions for blending with overlays is now hardcoded in the
shader. This was using harcoded numbers anyway, if this every becomes a
general OpenColorIO transform it can be changed, but for now there is no
point to add code complexity.
Ref D10273
CIE XYZ
=======
We need standard CIE XYZ values for rendering effects like blackbody emission.
The relation to the scene linear role is based on OpenColorIO configuration.
In OpenColorIO 2.0 configs roles can no longer have the same name as color
spaces, which means our XYZ role and colorspace in the configuration give an
error.
Instead use the new standard aces_interchange role, which relates scene linear
to a known scene referred color space. Compatibility with the old XYZ role is
preserved, if the configuration file has no conflicting names.
Also includes a non-functional change to the configuraton file to use an
XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier
since the matrix is the same one we have in the code now and that is also
found easily in the ACES specs.
Ref D10274
Create zero-byte manual page files `nasm.1` and `ndisasm.1` such that
nasm's `make install` step succeeds.
Installing nasm requires that its manual pages are built. This requires
local packages `asciidoc` and `xmlto` to be installed.
Not only does `asciidoc` pull in 110 MB of packages (itself +
dependencies), there is also no need for these manual pages. Nasm is
just used for building other dependencies, and not even part of our
precompiled libraries in SVN.
Reviewed By: sebbas
Differential Revision: https://developer.blender.org/D10396
- Move non-blender build targets into their own section.
- Expand 'make help' text, noting a local 'make deps' overrides.
- Note where the spell checkers word-list is maintained.
- Note on why sqlite is built without 'tcl'.
For the debug version of cython pip was trying to link
against the release version of python for some strange
reason. Passing some flags to explicitly target the
debug version fixes the issue.
Given other platforms do not have different builds for
debug/release this is not an issue there.
The following packages also have received updates:
- IDNA 2.10
- CHARDET 4.0.0
- URLLIB3 1.26.3
- CERTIFI 2020.12.5
- REQUESTS 2.25.1
- NUMPY 1.19.5
numpy has gained a hard dependency on cython:
- CYTHON 0.29.21
Notes:
- This only updates the build environment files,
once these are built, Blender can default to Python 3.9.
- The 'm' suffix for Python binaries/libs has been removed.
- The macOS patch in Python 3.7 is has been removed.
Reviewed By: sybren, campbellbarton, sebbas
Ref D10257
The repository information for cloning the OpenXR repository, rather than just
downloading the source archive, was outdated.
* Use the OpenXR-SDK repository link, not the OpenXR-SDK-Source one. Only the
former is needed, it contains pregenerated files with minimum dependencies.
The latter contains additional tools and the un-generated source files.
* Update the commit hash to the version we currently use, 1.0.14 (was 1.0.6).
Differential Revision: https://developer.blender.org/D10373
Reviewed by: Bastien Montagne
