Issues were:
* Abusing of `WITH_PYTHON_INSTALL_NUMPY` by both Audaspace and
Mantaflow.
- `PYTHON_INSTALL` options only decide whether we copy python (and
some extra modules) in our Blender installation. On linux it
makes much more sense to use global python installation.
- Now we have instead a proper `WITH_PYTHON_NUMPY`
* Bad assumptions regarding path of headers relative to path of python
module.
- In current Debian testing, modules are under `python3.9`
directory, while headers are under `python3` directory.
- Now we properly `find_path` for headers as well, modifying
`find_python_package` to take an optional argument for headers.
Note that the required changes done to `extern` libraries are in
blender-specific files that do not exist upstream.
Differential Revision: https://developer.blender.org/D9773
This enables the use of clang-tidy in the VS IDE.
To use it:
1 - Enable WITH_CLANG_TIDY in your cmake configuration
2 - From the Analyse pull down menu select Run Code Analysis on...
The analyser is currently not enabled by default on build
given it is quite slow and there are quite a few problems
it reports that we still need to deal with.
This commit expands the Windows-specific code in rBdca9aa0053f7 and Linux-specific code in rB33b7d53df08a.
It also fixes a capitalization issue in FindPugiXML.cmake
PugiXML was historically shipped hidden embedded into OIIO, the Grease
Pencil team had a requirement for an XML library recently so pugi seems
like a natural choice since it's not really a 'new' library, we just
turn an implicit dependency into an explicit one.
This commit expands the Windows-specific code in rBdca9aa0053f7 to
include Linux. macOS support will be handled in a later commit.
NOTE: run `cmake -U'*PUGIXML*' .` in the build directory to ensure CMake
finds PugiXML in the new location.
For details see D8628
CYCLES_TEST_DEVICES is a list of devices (CPU, CUDA, OPTIX, OPENCL). It is set
to CPU only by default.
Test output is now writen to build/tests/cycles/<device>, and the HTML report
has separate report pages for the different devices, with option to compare
between CPU and GPU renders.
Various GPU tests are still failing due to CPU/GPU differences, these are to be
fixed or blacklisted still.
Ref T82193
This separates out PugiXML that was previously
bundled by OIIO.
As this linux/mac libs are not available
this commit only contains the builder and windows
changes, and the option to enable pugixml is
guarded by a platform if, this can be removed
once all platforms have committed the svn libs.
For details see D8628
Becomes rather annoying to duplicate them across C/C++ GCC/Clang sets,
almost as if the test should test both C and C++, and to do it for all
compilers.
Solves strict warning in the upstream of Ceres library.
Use a more reliable method to check the availability of the flag than
compiler versions. Some compilers have different behaviors for
C and C++.
Reviewed By: campbellbarton, ChrisLend
Differential Revision: https://developer.blender.org/D9446
The issue was in `buildinfo.c`:
char build_c[xx]flags[] = BUILD_C[XX]FLAGS;
Non-escaped double-quotes were terminating the string early, and
causing the compile error. So use single-quotes.
This change removes the user-specific information from
macros like `__FILE__` and keeps it relative to top level
source or build (for generated files) directory.
It makes traces concise.
Added option `WITH_COMPILER_SHORT_FILE_MACRO` enabled by default.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D9386
Fixed a couple of typos in comments in CMakeLists.txt and GNUmakefile
Reviewed By: #platforms_builds_tests, mont29
Differential Revision: https://developer.blender.org/D9261
With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9179
`APPLE` platform handles ASan compiler and linker flags using
`add_compile_options` and `add_link_options`. {rB74bcb32c9f02}
Arguments in `CMAKE_{LANG}_FLAGS{_CONFIG}` are also passed to
`try_compile` which will fail due to linker errors, since link flags
are not set. `try_compile` is used by `find_package(Boost)` for
`thread` library.
See CMP0066 [1] also.
[1] https://cmake.org/cmake/help/latest/policy/CMP0066.html
Ref D8855
NanoVDB is a platform-independent sparse volume data structure that makes it possible to
use OpenVDB volumes on the GPU. This patch uses it for volume rendering in Cycles,
replacing the previous usage of dense 3D textures.
Since it has a big impact on memory usage and performance and changes the OpenVDB
branch used for the rest of Blender as well, this is not enabled by default yet, which will
happen only after 2.82 was branched off. To enable it, build both dependencies and Blender
itself with the "WITH_NANOVDB" CMake option.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8794
I didn't realize there were more duplicates while committing
{rBf1fee433be92}.
Original was added in {rB83f8223543f58c3b0881a03b6e9ddffff91}.
Duplicate was added in the merge {rB9e09b5c418c0a436e3c84ccf}.
Ref D8822
Setting `PLATFORM_LINKLIBS` is not required for clang, compiler and
linker flags are enough. Note that the change made in
{rBa4c5811e2127}) to `platform_apple.cmake` (appending to
`PLATFORM_CFLAGS`) has not been reverted. platform file shouldn't be
overwriting the flags.
`PLATFORM_LINKFLAGS` is overwritten by `platform_apple.cmake`, so no
point in setting it. Fixing that like `PLATFORM_CFLAGS` is out of the
scope of this change.
`PLATFORM_LINKFLAGS_DEBUG` has been replaced with generator expression
to include RelWithDebInfo and MinSizeRel build types also.
While testing for {rB40dcf686f04f}, compiler flags got mixed up and
non-working ASan configuration was committed.
Platform file, which is `include`d after the `CMAKE_C_FLAGS_DEBUG` etc.,
are set, overwrites those flags instead of appending to them. To fix this,
`PLATFORM_CFLAGS` is used to pass the `-fsanitize=*` flags to the C/C++
compiler.
Tested on fresh build using both Xcode and Ninja, with & without ccache.
Also silence a clang warning for multi-config generators:
the object size sanitizer has no effect at -O0, but is explicitly
enabled: -fsanitize=object-size [-Winvalid-command-line-argument]
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8879
For work the GP team plans to land soon (T79877) potrace was taken
on as an additional optional dependency.
This diff adds building the library to the deps builder and takes
care of the integration into the build-system with the `WITH_POTRACE`
cmake switch.
Differential Revision: https://developer.blender.org/D8662
Reviewed by: brecht, sergey
This makes it error-proof to disable/enable experimental features
during the release cycles. Since it is handled by CMake it should always
work reliably now (not depending on someone turning this on and off).
Reviewed by Sergey Sharybin.
Similar to {rB0a5f7061369d53b4eac55362ad2}
but also for Xcode and Ninja multi-config.
This silences 44 pairs of warnings like:
/bin/rm -f build_full/bin/tests/BLI_ghash_performance_test
"build_full/CMakeScripts/XCODE_DEPEND_HELPER.make:42: warning:
ignoring old commands for target
`build_full/bin/tests/BLI_ghash_performance_test'"
/bin/rm -f build_full/bin/tests/BLI_ghash_performance_test
"build_full/CMakeScripts/XCODE_DEPEND_HELPER.make:3523: warning:
overriding commands for target
`build_full/bin/tests/BLI_ghash_performance_test'"
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8815
This change allows macOS developers to use
`WITH_COMPILER_ASAN` with every generator.
`CMAKE_C_IMPLICIT_LINK_DIRECTORIES` on macOS points to
`Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib`
which is not where the Sanitizer libraries are.
To link the library, rpath could be used but that seems complex,
so linker flags are passed as the documentation says. [1]
If users have `ASAN_OPTIONS=detect_leaks=1` in their environment
variables, it should be removed to avoid a feature-unsupported error
while compiling.
[1]: http://clang.llvm.org/docs/AddressSanitizer.html#usage
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8817
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
MSVC already builds with the /std:c++17 flag but for
'reasons' [1] MSVC still gives the wrong value for the
__cplusplus define.
This change sets an additional cxx flag on supported
compilers to allow the compiler properly identify
C++17 support.
This resolves 2 warnings coming out of bullet about
the register keyword being deprecated.
[1] https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/
When the OSL_ROOT variable is set this is ignored
by findpackage on cmake < 3.12. CMake 3.12 and up
also ignore it and warn about it. This change
tells cmake it is OK to use the variable and
stop warning
During alpha the user preferences > experimental featuers are available
to prevent merge issues and allow developers to seek feedback.
This needs to be manually turned off when we branch for beta, otherwise
the RNA of the incomplete features will be exposed.
For 2.90 release this should not be exposed in the RNA API.
In master this needs to be ON by default, that's all.
Differential Revision: https://developer.blender.org/D8589
Required for the new boolean code, disabled by default
until all platforms have landed the libs and the boolean
code actually lands in master.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8384
This bumps the minimally required CMake version from 3.5 to 3.10, as
discussed in D8405.
Since D7649 landed, there has been the `gtest_discover_tests()` call to
discover individual unit tests in `bin/tests/blender_test`. This
function was introduced in CMake 3.10.
Since there were no complaints about this incompatibility, I suspect
that a newer version is already in use by the majority of the
Blender-building people.
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
This commit introduces a new way to build unit tests. It is now possible
for each module to generate its own test library. The tests in these
libraries are then bundled into a single executable.
The test executable can be run with `ctest`. Even though the tests
reside in a single executable, they are still exposed as individual
tests to `ctest`, and thus can be selected via its `-R` argument.
Not yet ported tests still build & run as before.
The following rules apply:
- Test code should reside in the same directory as the code under test.
- Tests that target functionality in `somefile.{c,cc}` should reside in
`somefile_test.cc`.
- The namespace for tests is the `tests` sub-namespace of the code under
test. For example, tests for `blender::bke` should be in
`blender::bke:tests`.
- The test files should be listed in the module's `CMakeLists.txt` in a
`blender_add_test_lib()` call. See the `blenkernel` module for an
example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7649
