This is to help ensure buildbot builds are correct, while still gracefully
disabling features in user/developer builds.
* Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be
enabled due to missing libraries or other reasons. Add new macro
set_and_warn_library_found used everywhere features were being
automatically disabled.
* Remove code from Windows and macOS for various libraries that would
automatically disable features. set_and_warn_library_found could be
used here also, but we are generally assuming the precompiled libraries
are complete and only test for availability when libraries are just
added.
Differential Revision: https://developer.blender.org/D16104
The opencollada dependency will be using an external xml2 library
for 3.4. This change allows to build against both old and new
style lib folders.
As it is a C library it did not need a special debug version.
THis is bumping dependencies to fix known CVEs, with the exception of
OpenImageIO which also includes bugfixes for performance and correctness
with some image types.
zlib 1.2.12 -> 1.2.13
freetype 2.11.1 -> 2.12.1
openimageio 2.3.13.0 -> 2.3.20.0
python 3.10.2 -> 3.10.8
openjpeg 2.4.0 -> 2.5.0
ffmpeg 5.0 -> 5.1.2
sndfile 1.0.28 -> 1.1.0
xml2 2.9.10 -> 2.10.3
expat 2.4.4 -> 2.4.9
openssl 1.1.1g/i -> 1.1.1q
sqlite 3.31.1 -> 3.37.2
Notable changes:
* AOM: the hack we had in place to make it not detect pthreads on windows no
longer worked with a more recent cmake version. Disabled pthreads with a
diff on Windows.
* Python: embedded copy of zlib 2.1.12 swapped out for our 2.1.13 copy with
some folder manipulation on Windows.
* Freetype: was harbouring a copy of zlib 2.1.12 as well, so that had to end.
* FFmpeg: patch used to fix D11796 is no longer needed. Add new patch to deal
with simple_idct.asm generating an object file with no sections in it,
backport from upstream commit.
* TinyXML: still being downloaded but no longer used by OpenColorIO, removed.
* GMP applied upstream patch to fix CVE-2021-43618, as there is no release yet.
* SQLite and Libsndfile patches no longer needed.
Includes contributes by Ray Molenkamp, Campbell Barton and Brecht Van Lommel.
Ref T101403
Differential Revision: https://developer.blender.org/D16269
For some compiler and linker configurations, linking would fail as the
wayland libs were linked at a high level and not at the actual code
where they were needed.
After talking to Campbell, we decided to clean up this part and now
only link both the X11 and Wayland libs where they are used.
When using pre-compiled libs, reference the bundled wayland headers,
needed so the headers from the bundled wayland-scanner are compatible.
Part of D16091.
It fixes SYCL runtime issues in Debug builds that were due to mixing
Release and Debug MSVC runtimes.
This commit also removes specific handling of dpcpp compiler executable
to simplify the CMake implementation. Using it like clang++ works and
clang++ executable is also available from Intel oneAPI DPC++ compiler in
case it doesn't.
This is a minimal set of changes, allowing a lot of cleanup that can
happen afterward as it allows sycl method and objects to be used outside
of kernel.cpp.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D15397
To avoid issues with install_deps. If we more generally switch to using
CMake configs then perhaps this code can be deduplicated again or at
least simplified.
This is needed to ensure and up to date "wayland-scanner" is used,
as versions before 1.20.0 generate headers incompatible with
dynamic linking (WITH_GHOST_WAYLAND_DYNLOAD).
As the centos7 version of wayland is 1.15 so make this part of Blender's
dependencies on Linux.
We intend to enable Wayland for Blender 3.4 release, this is needed for
the build-bot.
Reviewed By: brecht
Ref D16074
Match minimum supported versions from the WIKI [0] by raising them to:
- GCC 9.3.1
- CLANG 8.0
- MVCS 2019 (16.9.16 / 1928)
Details:
- Add CMake checks that ensure supported compiler versions early on.
- Previously GCC per-processor version checks served to exclude
`__clang__`, in some cases this has been replaced by explicitly
excluding `__clang__`. This was needed as CLANG treated some of these
flags differently to GCC, causing the build to fail.
- Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround.
- Remove linking error workaround for old MSVC versions.
[0]: https://wiki.blender.org/wiki/Building_Blender
Reviewed by: brecht, LazyDodo
Ref D16068
This is already the case for most CMake usage.
Although some find modules are an exception to this, as they were
originally maintained externally they use some different conventions.
Also corrected bad indentation in: intern/cycles/CMakeLists.txt
The buildbot will call this script to create a binary .whl file that can be
easily installed through pip.
This wheel will only work with the same Python version used for Blender.
Other minimum system requirements are the same as regular Blender builds.
Includes contributions by Campbell Barton.
Differential Revision: https://developer.blender.org/D15957
* Use Python executable from lib folder since it's not installed.
* Make bpy module test work for portable install.
* Disable gtests which don't work with different Python link flags
and shared library locations.
Ref D15957
A continuation of previous fix for malloc hooks which got removed
from the new glibc library.
The pre-compiled jemalloc has definitions which interpose hooks
in glibc leading to linking errors with multiple hook definitions.
A simple fix is to skip doing the workaround when using jemalloc
from pre-compiled libraries.
This will likely be revisited in the future, but for now it is
important to fix compilation errors for developers.
Build against Python from precompiled libraries by default, instead of
requiring framework from python.org package install. The resulting bpy module
can still be used with any Python install of the same version.
Use the same CMake find module as Linux. This simplifies code, and makes it
possible to manually set PYTHON_* variables in CMake configuration.
Remove WITH_PYTHON_FRAMEWORK option for regular Blender build, as this doesn't
work well due to missing required Python packages. Advanced users can still
set PYTHON_ROOT_DIR=/Library/Frameworks/Python.framework/Versions/3.10 for
the same result.
Same as other build options, don't make it a hard requirement to have
Wayland libraries installed when it gets enabled by default.
Also fixes wayland-protocols not being found on the buildbot.
PLATFORM_BUNDLED_LIBRARIES gathers shared libraries that will be installed
to the lib/ folder. The Blender executable gets a relative rpath pointing to
this folder as part of the install step.
The build rpath is different and uses absolute paths, so that it works for
executables like tests that are in different locations, and to support the
case where the build and install folders are different.
The system is already used for the OpenMP library on macOS. But on Linux it
will only kick in once we start using shared libraries for dependencies.
This also removes Mesa libraries from the old location, as these would cause
Blender to start with software OpenGL.
Ref T99618
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
Because of the recent changes to our core fonts,
Freetype has to support Woff2 fonts or Blender will segfault on startup.
This adds an explicit check for this to inform people compiling Blender
about this requirement.
Instead of specifying which symbols to hide, we hide all and make a few
visible. Some users may be relying on calling internal Blender functions,
but Windows is already hiding all of them and this is just not supported.
Fixes T99900: crash with some third-party Python libraries since OneAPI
Ref T76442
Differential Revision: https://developer.blender.org/D14971
This is a refresh of our current FFmpeg 5.0.0 (unchanged) version with the
following changes:
* libvpx all platforms: enable SSE3/4/AVX/AVX2 instruction sets. libvpx has a
proper CPUID check in place and will not call the faster kernels unless it is
sure the CPU supports it. So we can safely enable this, this partially
resolves T95743 (completely on Linux and macOS).
* libvpx Windows - threading was disabled due to a shared dependency on
libwinpthreads.dll which we prefer not to distribute. However when configure
cannot find pthreads it will happily fall back on a win32 threads based
emulation layer. This also resolves the final part of T95743.
* libaom-av1 - new dependency required for D14920, this is a somewhat odd
dependency, it's cmake based, but still needs the perl environment setup, so
we have to setup the env and call cmake our selves for the configure, build
and install commands. This dep has the same libwinpthreads issue as vpx on
Windows, however since it's cmake based, it's easier to prevent cmake from
detecting it.
Differential Revision: https://developer.blender.org/D15399
Add intern/wayland_dynload which is used when WITH_GHOST_WAYLAND_DYNLOAD
is enabled (off by default). When enabled, systems without Wayland
installed will fall back to X11.
This allows Blender to dynamically load:
- libwayland-client
- libwayland-cursor
- libwayland-egl
- libdecor-0 (when WITH_GHOST_WAYLAND_LIBDECOR is enabled).
This patch adds a new Cycles device with similar functionality to the
existing GPU devices. Kernel compilation and runtime interaction happen
via oneAPI DPC++ compiler and SYCL API.
This implementation is primarly focusing on Intel® Arc™ GPUs and other
future Intel GPUs. The first supported drivers are 101.1660 on Windows
and 22.10.22597 on Linux.
The necessary tools for compilation are:
- A SYCL compiler such as oneAPI DPC++ compiler or
https://github.com/intel/llvm
- Intel® oneAPI Level Zero which is used for low level device queries:
https://github.com/oneapi-src/level-zero
- To optionally generate prebuilt graphics binaries: Intel® Graphics
Compiler All are included in Linux precompiled libraries on svn:
https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for
Windows precompiled binaries but for the graphics compiler, available
as "Intel® Graphics Offline Compiler for OpenCL™ Code" from
https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html,
for which path can be set as OCLOC_INSTALL_DIR.
Being based on the open SYCL standard, this implementation could also be
extended to run on other compatible non-Intel hardware in the future.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D15254
Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com>
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
GLEW does not support GLX and EGL at the same time, and the distribution version
is likely to have GLX.
This also refactors the code so all OpenGL related CMake options are together.
Differential Revision: https://developer.blender.org/D12034
Add WITH_GHOST_WAYLAND_DBUS option, so Blender can be built without
DBUS support. Currently it's only used to access the cursor theme.
Without this the "default" cursors are used instead.
Disabling this since it adds an additional dependency for a minor gain
in functionality, with the benefit of removing a library requirement.
There is also a problem where Blender hangs on startup for ~5 seconds
when DBUS isn't running. Eventually it would be good to be able to avoid
this problem without a build option.
This implements client-side window decorations for moving and resizing
windows and HiDPI support.
This functionality depends on the external project 'libdecor' that is
currently a build option: WITH_GHOST_WAYLAND_LIBDECOR.
Reviewed by: brecht, campbellbarton
Ref D7989
Blender will respect Windows "Dark Mode" setting for title bar color.
See D14847 for details.
Differential Revision: https://developer.blender.org/D14847
Reviewed by Ray Molenkamp
This patch has also been contributed upstream, so will not be needed anymore
soon. Also automatically clear cached variables for new nanovdb location in
libs.
Building against the existing 3.1 libraries should continue to work, until
the precompiled libraries are committed for all platforms.
* Enable WebP by default.
* Update Windows for new library file names.
* Automatically clear outdated CMake cache variables when upgrading to new
libraries.
* Fix static library linking order issues on Linux for OpenEXR and OpenVDB.
Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel.
Ref T95206
Adds support for linking with some of the dependencies of a USD
build instead of the precompiled libraries from Blender, specifically
OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the
precompiled libraries from Blender, since they are linked statically
anyway so it does't matter as much. Plus they have interdependencies
that are difficult to resolve when only using selected libraries from
the USD build and can't simply assume that USD was built with all
of them.
This patch also makes building the Hydra render delegate via the
standalone repository work and fixes various small issues I ran into
in general on Windows (e.g. the use of both fixed paths and
`find_package` did not seem to work correctly). Building both the
standalone Cycles application and the Hydra render delegate at the
same time is supported now as well (the paths in the USD plugin JSON
file are updated accordingly).
All that needs to be done now to build is to specify a `PXR_ROOT`
or `USD_ROOT` CMake variable pointing to the USD installation,
everything else is taken care of automatically (CMake targets are
loaded from the `pxrTargets.cmake` of USD and linked into the
render delegate and OpenSubdiv, OpenVDB and TBB are replaced
with those from USD when they exist).
Differential Revision: https://developer.blender.org/D14523
