- Fix using forward declarations when extracting struct information as
it causing this check to be ignored.
- Fix extracting comments which sometimes included code fragments.
- Fix extracting the outer comment for struct declarations on a single
line.
- Skip source files in the build directory.
request from Thomas, to update the licensing document he needs
a list of all dependencies their versions and their homepage.
for all deps hosted on github the script will do its best to
figure out the landing page, for all others DEPNAME_HOMEPAGE
will have to be set in versions.cmake
To ensure this information is always supplied, the script will
error out with a fatal error informing whoever is working on
the builder to supply this information.
Pull Request: https://projects.blender.org/blender/blender/pulls/109013
When an offline render was done side by side render preview, further
render preview updates requiring BVH to be rebuilt would trigger a
crash.
This will be fixed upstream the same way in Embree 4.2.
Pull Request: https://projects.blender.org/blender/blender/pulls/109966
This utility uses Python's clang module to validate comments intended
to match the struct member names. `cmake_static_check_clang.py` has
been written to support adding other checkers in the future.
`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
