Two issues there
- it was picking up release mode libs for oiio/tbb
- TBB had both debug and release libs in a variable that should only
have a single library causing a cmake error.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Fix the issue when upstream workflow is used and the addons fork does
not yet have the release branch. In this case create a local branch
which is based on the upstream/<branch> but does not track anything.
Typically with such workflow the local branches will track origin, but
since the origin does not have the branch yet it is not possible to
track it.
Test plan:
- Use upstream workflow
- Have a fork of addons, which does not have blender-v3.6-release
- Run make update
The error message:
```
Updating scripts/addons ...
git fetch origin
git fetch upstream
git checkout -t origin/blender-v3.6-release
fatal: 'origin/blender-v3.6-release' is not a commit and a branch 'blender-v3.6-release' cannot be created from it
make: *** [update] Error 128
```
Pull Request: https://projects.blender.org/blender/blender/pulls/108197
Code gen bugs can happen, ad usually they can be worked around
MSVC 17.6 is not one of those cases:
59% tests passed, 120 tests failed out of 296
There really is no other choice than to refuse to build with this
compiler. Alternates that CAN be used are both 17.5 and the current
17.7 preview builds.
Upstream tracking ticket kindly submitted by @deadpin :
https://developercommunity.visualstudio.com/t/vs176/10293729
If a compiler is released in the 17.6.x series that has the bug
fixed, we can contract the range of blacklisted compiler versions
to cover just the affected range, for now however all of 17.6 marked
bad
Upgrade to the latest SDK, and enable in daily and release builds where it's
available as an option under Preferences > System.
There are some known limitations, see #104110 and release notes.
Pull Request: https://projects.blender.org/blender/blender/pulls/105538
When Python is not found, inform developers how they can use a newer
version. Even though it's not officially supported - we typically keep
the latest stable version of Python working.
Preparation for the the 3.6 library update landing.
The filenames for these libs will change a little bit and 3.6 will add
new library for the fp32 version of fftw.
After recent Linux library updates. The EMBREE_SYCL_SUPPORT variable that
this relied on was not cached.
Always install the sycl shared libraries regardless of build options, as
we do for other shared libraries.
Other shared libraries already do this, but for TBB it was off by default.
The conflict would happen when LD_LIBRARY_PATH is set which overrides rpath,
either manually by the user or by the Steam launcher.
Ref #107385, #104895
Pull Request: https://projects.blender.org/blender/blender/pulls/107587
Support string size debug so it can be used for regular development.
It works be writing values into strings, ensuring the buffer size
given is actually available. Developers can use this with memory
checking tools such as ASAN/valgrind to force an error when
the value used for the size of a buffer is larger than the buffer.
Resolve remaining issue with RNA using BLI_strncpy* in generated
callback functions where the size argument didn't represent the
size of the destination buffer.
This is automatically enabled along with ASAN for the
blender_developer.cmake configuration.
Ref PR !107602.
This brings the following improvements:
- Implementation of _MM_SET_FLUSH_ZERO_MODE and _MM_SET_DENORMALS_ZERO_MODE
- Implementation of _mm_round_ss
Does not seem to be any performance impact with just this upgrade.
Pull Request: https://projects.blender.org/blender/blender/pulls/107396
* Add HIP-RT API functions and library loading
* Add more HIP API types and functions
* Find HIP linker executable in CMake module
* New CMake module to find HIP-RT SDK
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Ref #105538
libdecor is not a hard requirement, so only fail the configure phase if
the building in strict mode.
This makes it behave like most other dependencies in Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/107304
When using Xcode version 14.3 on Apple Silicon hardware a number of
regression tests fails. This change fixes this problem.
The root cause comes to the floating point contraction. It was already
disabled for GCC on Linux, but not for Clang on neither of Linux or
macOS.
Also corrected the comment about Clang default, as it as set to on
somewhere in 2021.
Pull Request: https://projects.blender.org/blender/blender/pulls/107136
Using the new HIP SDK 5.5 that includes a fix for the compiler bug.
This also enables the light tree.
For Linux the binaries are still disabled. ROCm 5.5 is planned to
include the same fix but not released yet. When that happens we
should be able to enable Linux as well.
Ref #104786Fix#104085
Pull Request: https://projects.blender.org/blender/blender/pulls/107098
The dpcpp folder grew from 200M to 500M with the last update
due to lld being enabled and having 5 different copies in the bin
folder. We do not need to ship lld so it can be safely removed.
However previous harvest cleaned up the build folder before copying
the libs to their final destination in output, this will no longer
work, since we actually do need lld to build embree.
So copy to the full build folder to output first, then remove the
binaries we do not need. Embree will use the binaries in the build
folder so it will be unaffected by this.
This reverts commit df096eab77.
There is a corner case for when WITH_CYCLES_ONEAPI_BINARIES is set to on
and later turned off during config, in case there is no ocloc.
GCC did not support mold when support was initially added,
since then GCC has been updated to add support, removing the need
to point to a binary directory containing an alternative `ld` command.
Support for MOLD_BIN CMake option has been kept as mold may be installed
to standard location.
This checkin will use OIIO to replace the image save/load code for BMP,
DDS, DPX, HDR, PNG, TGA, and TIFF.
This simplifies our build environment, reduces binary duplication,
removes large amounts of hard to maintain code, and fixes some bugs
along the way.
It should also help reduce rare differences between Blender and Cycles
which already uses OIIO for most situations. Or potentially makes them
easier to solve once discovered.
This is a continuation of the work for #101413
Pull Request: https://projects.blender.org/blender/blender/pulls/105785
There is a `KeyError` exception when the `install_linux_packages.py` build script is ran with `--distro-id`:
```console
$ ./build_files/build_environment/install_linux_packages.py --distro-id arch
INFO: Distribution identifier forced by user to arch.
Traceback (most recent call last):
File "file:///blender/./build_files/build_environment/install_linux_packages.py", line 1656, in <module>
main()
File "file:///blender/./build_files/build_environment/install_linux_packages.py", line 1646, in main
distro_package_installer = PackageInstaller(settings) if settings.show_deps else get_distro_package_installer(settings)
File "file:///blender/./build_files/build_environment/install_linux_packages.py", line 1570, in get_distro_package_installer
return DISTRO_IDS_INSTALLERS[get_distro(settings)](settings)
KeyError: None
```
This happens because the `get_distro` function returns `None` if the distribution ID is forced with the `--distro-id` option, when it should return the provided value.
Pull Request: https://projects.blender.org/blender/blender/pulls/106461
The assets are required to build proper Blender release, so they can not be
skipped from packing.
The packing ignores the `working` directory as it seems to be big and sounds
that it is not needed for the release.
The assets are bundled under the `release/datafiles/assets` folder in the
blender sources. This is where they will reside after switch to the Git LFS.
Pull Request: https://projects.blender.org/blender/blender/pulls/106536
Use the latest Wayland version, resolves inverted track-pad scroll
direction #104272 by adding support for physical scroll direction.
Updates to GHOST/Wayland have already been made.
`PLATFORM_BUNDLED_LIBRARIES` was installing right next to the blender
executable rather than the `blender.shared` folder,
`PLATFORM_BUNDLED_LIBRARIES` wasn't used very much on windows, just
by the ONEAPI code which likely wasn't aware this plumbing was
still missing.
This diff adds support for using `PLATFORM_BUNDLED_LIBRARIES` on
windows in both debug and release configurations.
You can differentiate between a .dll being installed for debug/release
or all configurations, by prefixing the library with either `DEBUG`,
`RELEASE` or `All`, if no prefix is given `ALL` is assumed.
Pull Request: https://projects.blender.org/blender/blender/pulls/106348
Depending on newer API's could cause build failure for existing
builds using wayland-protocols outside of Blender's 'lib' directory.
Now the existence of the most recent XML file is checked on each CMake
execution, resetting the cache when not found so the protocols in
`../lib/linux_x86_64_glibc_228/` will be used instead.
