`list_assert_duplicates` validates a list that should contain no
duplicates, contains no duplicates, with scope keywords now being
allowed in `INC` sections, there is the situation where multiple
include paths can have the same scope set on them causing
`list_assert_duplicates` to error out.
To remedy this we remove the scope keywords from the list first,
before running the test.
USD has recently renamed their repository from USD to OpenUSD leading
to a change in the URI for this dep and the hash for the previously
released USD 23.05 since the tarball now will have the source in the
OpenUSD-23.05 folder.
This is the minimal change required to start using modern CMake in the
blender build system. This change is designed to allow small
incremental changes to the build system rather than doing it in one
big bang which would be unmaintainable (for me)
The biggest functional change is, previously all libraries in the
`LIB` section of a `blender_add_lib` call had the `INTERFACE` scope,
which is rarely, if ever the correct scope. This diff changes this to
`PRIVATE`
Concrete implications of this diff :
The `LIB`, `INC` and `INC_SYS` sections of an `blender_add_lib` call
now allow scoping keywords (`PUBLIC`, `PRIVATE,` `INTERFACE`) to
declare the scope of the dependency.
Right now the only library using any modern cmake is
`bf_intern_atomic` which is an header only interface library that will
just advertise its include directories.
This allows us to clean up any `CMakeLists.txt` that adds
`../../../intern/atomic` to its `INC` section to remove it in `INC` by
adding a `PRIVATE bf_intern_atomic` to the `LIB` section.
Pull Request: https://projects.blender.org/blender/blender/pulls/107858
Python versions before 3.10 did not have the
`platform.freedesktop_os_release` utils, use the trick based on looking
for distro-specific version files instead as fall-back (same as what was
done in the previous `install_deps.sh` bash script).
When using the `WITH_LINKER_LLD` option, the logic to find the `ld.lld`
binary and actually tell the build system to use it was specific to GCC.
I've copied the Clang-specific logic for Mold and adjusted it to find
LLD.
Not entirely sure why this is necessary, as LLD is actually Clang's
linker. However, without this change, CMake would use regular old slow
`ld` to link.
Pull Request: https://projects.blender.org/blender/blender/pulls/108884
This fixes#108487 by applying upstream OIIO commit 8da473e254
This commit fixes the deps builder to include the patch, the actual
bug will not be fixed until the platform maintainers update the OIIO
library in SVN.
Currently on Windows some dependencies are built with MinGW/GCC 3.x
this commit removes that, in favor of building them with MSVC
via msys2. This will make it easier in the future to offer Win/Arm64
builds of blender.
Notable changes:
- This change drops support for the external libxvid library in favor
of ffmpegs built in support for this format. This has been done with
permission from the VFX module.
Pull Request: https://projects.blender.org/blender/blender/pulls/108983https://projects.blender.org/blender/blender/pulls/105502
idiff sometimes locks up while shutting down when the CPU is
oversubscribed. While blender does not rely on the idiff tool
the tests that run on the CI environment do, which causes tests
to occasionally fail due to a timeout.
The root cause is a bit complex but can be found on the oiio tracker
at https://github.com/OpenImageIO/oiio/issues/3851
This change fixes idiff by :
1- Shutting down the thread pool before the main function exits
2- Have the shutdown wait for the pool threads to actually join, to
prevent the OS from forcefully terminating them while they could
potentially still be holding a lock.
This reverts commit 451751380c.
Seems like this broke linux/mac, likely needs to detect of libxvid
is there or not. For now revert until we sort this out.
Currently, Windows some dependencies are built with MinGW/GCC 3.x
this commit removes that, in favor of building them with MSVC
via msys2. This will make it easier in the future to offer Win/Arm64
builds of blender.
Notable changes:
- This change drops support for the external libxvid library in favor
of ffmpegs built in support for this format. This has been done with
permission from the VFX module.
Pull Request: https://projects.blender.org/blender/blender/pulls/105502
This is fixed in newer boost versions, but stick to the existing version now
for VFX platform compatibility. This change only affects macOS libraries,
since no other platform uses libc++.
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.
