It's not clear what these are used for as they seem like recent
additions and are set to "NOT-FOUND" even when tiff/freetype are found.
Marking as advanced instead of removing so as not to interfere with
freetype/tiff finding logic.
Exceptions:
* Links to personal wiki pages
* Pages that are not in the new developer docs yet (like Human Interface Guidelines)
* tools\check_wiki\check_wiki_file_structure.py needs a refactor
Previous code was using the 'nuclear' SAN weapon `exitcode=0`, which
essentially makes testing ignore all sanitizer errors.
This commit removes this option, and instead uses the suppression
list from Blender source repository (`tools/config/analysis/lsan.supp`)
for the leak sanitizer.
It also enables the `allocator_may_return_null` for the address sanitizer.
This should only be needed for one test (the `guardedalloc` one), but for
now it is simpler to define it for all tests. This can be refined at a
later time.
Pull Request: https://projects.blender.org/blender/blender/pulls/116635
Along with regular fixes and improvements,
this removes a warning on startup for Linux, see:
https://github.com/kcat/openal-soft/issues/554
Some deprecated CMake variables were removed and needed to be renamed.
Note that the previous URL from http://openal-soft.org/
is no longer responsive, using the GITHUB URL instead.
Ref !116877
The current handling had a fairly bad issue: multiple calls to
`set_tests_properties` to set envvars of a same test.
This does not work, only the last call is effective, all previous
ones have absolutely no effect.
This has been addressed by moving all 'set envvar for test' logic into a
single CMake function, `blender_test_set_envvars`.
This function takes optional extra envvars if needed, and define a set
of default ones (currently, `PATH` from `PLATFORM_ENV_INSTALL` if
defined, and the 'nuke' `exitcode=0` `LSAN_OPTIONS` if relevant).
NOTE: The way `blender_test_set_envvars` handles extra envvars passed to
it as parameter is fairly basic and unsafe, in that there is no check
whether a same envvar is defined more than once. Think for now this is
an acceptable limitation.
NOTE: Although this commit _should_ be a non-functional change one, the
unification of the handling of all envvars makes it hard to ensure there is no
side effects.
The `PATH` envvar e.g. was set to either `PLATFORM_ENV_INSTALL` if defined,
or a copy of that variable's definition, but only in Windows case. So technically,
the behavior for this envvar is changed.
This commit adds a new helper to define expected properties when a
target needs to use the unity build feature.
That new helper does what was already done for existing cases, and in
addition add the target to the Ninja 'heavy' pooljobs if relevant.
Pull Request: https://projects.blender.org/blender/blender/pulls/116791
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
The warning was introduced with XCode 15 and conflicted with some
assumptions in the CMake. Even without actual cyclic dependency
between targets CMake might decide to pass library multiple times
to the linker, to ensure all its users find symbols from it.
This behavior is expected to be tweaked in the upcoming CMake
version, but until it is released and became widely used by all
Blender macOS developers silence the warning.
Pull Request: https://projects.blender.org/blender/blender/pulls/116718
* Different fix for Mantaflow linker warnings that works with new OpenVDB.
* Use new linker for arm64 as it no longer produces warnings with latest
Xcode. Still use the old one for x86_64 as some warnings remain.
* Fix wrong x86_64 build target in deps builder.
For the upcoming 4.1 libraries.
Ref #113157
Pull Request: https://projects.blender.org/blender/blender/pulls/116708
OIIO was including imaths half.h when it did not
need to, leading to build errors in lite builds.
This issue had been fixed already upstream but
was not yet included in the version we use.
- OIDN doesn't need to be build for debug builds on windows, while
it's mostly C++ code its public API is C
- Python was not found by the HIP build
- Level Zero was downloaded during the build.
New include directory variable from [0] was only set for WIN32,
causing openimageio to fail to build with libraries updated for 4.1.
[0]: 802ac5ba5afc04a2c4bdd72ef52df281d9065824
When storing multiple binaries in a fatbinary, ocloc stores Intel
Graphics binaries for specific devices and these don't get found when
the device doesn't match fully.
Blender compiles one binary per generation rather than per device, to
gain space and compile time.
We introduce a patch at ocloc level to work around this behavior that
otherwise leads to binaries not being found and recompilation being
attempted.
Pull Request: https://projects.blender.org/blender/blender/pulls/115750
The build scripts are still referring to gpu tests as being opengl.
Although they can also use Metal or Vulkan. This PR only replaces
the work `opengl` with `gpu` for build options.
Special note is that the windows argument `with_opengl_tests` is
also replaced with `with_gpu_tests` for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/116030
The NanoVDB headers are not compatible with Metal due to missing address
space qualifiers. We currently have a big patch for NanoVDB header
files, which is difficult to update for OpenVDB 11. Instead extract a
few hundred lines of code from NanoVDB to do just what we need.
Pull Request: https://projects.blender.org/blender/blender/pulls/115992
Simple string replacement failed when one compiler was the exact
prefix of another (`clang` & `clang++` in this case),
resolve by performing string replacement on the list items.
We disabled SSE for OIIO headers in the days we still supported
32 bit builds, as it was giving build errors there. OIIO handles
this internally now so we no longer need to explicitly disable it,
also we stopped shipping 32 bit quite a while ago
Asserts historically only have been on in debug builds, however
running the tests in a debug configuration takes a while especially
if Cycles is enabled.
This adds WITH_ASSERT_RELEASE to enable asserts in release
configurations. It is enabled for "make developer" , and will also
be used for CI.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115071
vcpkg somewhat forcefully injects itself into the build system
causing some work stations to use the vcpkg headers/libs rather than
the headers from our lib folder,we added some mitigation against this
in 34b3a9583ac2433dd8d223d2bd098adc30bc72bd but still the occasional
user with build issues showed up, this should nip that in the bud once
and for all.
Harfbuzz and FriBiDi are included in our external libraries for all
platforms. This PR adds the glue to make them available as optional
build components (off by default).
Pull Request: https://projects.blender.org/blender/blender/pulls/114947