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
Enabling all `make deps` dependencies with the exception of Embree and OIDN.
After that, Blender can be compiled on an Apple Silicon Mac just like on any
Intel based Mac. There are still compiler warnings that need to be
investigated and there are probably a couple of bug still to be discovered
and to be fixed.
Most patches to the dependencies are simple and are about disabling SSE and
setting the proper architecture to compiile for. Notable exception is Python,
where I back ported a yet to be accepted PR for upstream Python:
https://github.com/python/cpython/pull/21249
Cross compiling or buliding a Universal Binary is not supported yet.
The minimum macOS target version for x86_64 remains at 10.13, the target
for arm64 is 11.00.
Differential Revision: https://developer.blender.org/D8236
Clang Tidy is a Clang based "linter" tool which goal is to help
fixing typical programming errors.
It is run as a separate compile step of every file, which slows
compilation down but allows to fully analyze the file the same
way as compiler does and catch non-trivial bugprone cases.
This change includes:
- CMake option called `WITH_CLANG_TIDY` which enables Clang Tidy
linter tool on all source in the `source/` directory.
This option is only available on Linux, as it is currently the
easiest platform to get the Clang Tidy toolchain to work.
- CMake module which is aimed to find latest available Clang Tidy.
- Set of rules which allows to have Blender fully compiled without
extra issues.
The goal of this change is to provide a base ground so that solving
all the warnings can happen later on, as a team effort.
It should be possible to use Clang Tidy side-by-side with both GCC
and Clang, but there seems to be some tweaks to be done in CMake to
make it really work for Blender. For now use Clang toolchain if
there are issues with GCC+Clang Tidy.
It will be worked on in the nearest future to bring seamless
experience for all configurations.
Currently there is no official way of getting Clang Tidy on macOS,
and on Windows there are some difficulties of hooking up Clang Tidy
from LLVM package to the MSVC compiler toolchain.
The actual warnings in the code will be addressed as a part of the
Code Quality Days, task T78535.
Differential Revision: https://developer.blender.org/D7937
This replaces the cmake options `WITH_NEW_OBJECT_TYPES` and
`WITH_NEW_SIMULATION_TYPE` with two experimental userpref settings:
* `use_new_particle_system`: Enables the point cloud type and the simulation editor.
* `use_new_hair_type`: Only displays the add-operator in the add menu for now.
Note, in the current state you can't do anything productive with the new particle
system or the new hair type. Features will be added step by step in the upcoming
weeks and months.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8096
