Cr8-xyz/blender
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
main
blender/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2934 lines
110 KiB
CMake
Raw Permalink Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-16 00:20:26 +10:00
# SPDX-FileCopyrightText: 2006 Blender Authors
License headers: use SPDX-FileCopyrightText for CMake files
2023-06-14 22:49:59 +10:00
#
File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-11 09:07:11 +11:00
# SPDX-License-Identifier: GPL-2.0-or-later
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Early Initialization
# NOTE: We don't allow in-source builds. This causes no end of troubles because
formatting edits only
2011-09-30 15:51:58 +00:00
# all out-of-source builds will use the CMakeCache.txt file there and even
set main() argv functions to be const char * also set minimum cmake version to 2.8
2011-02-19 12:05:20 +00:00
# build the libs and objects in it.
CMake: Give error on attempts to generate within the sources with instructions on how to do it out-of-source
2006-12-13 02:57:57 +00:00
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
minor changes - remove some warnings - fix typos - cmake allow in-source build (when WITH_IN_SOURCE_BUILD is defined) - cmake, use an explicit list of rna files (don't glob)
2011-04-21 05:49:47 +00:00
if(NOT DEFINED WITH_IN_SOURCE_BUILD)
message(FATAL_ERROR
"CMake generation for blender is not allowed within the source directory!"
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
"\n Remove \"${CMAKE_SOURCE_DIR}/CMakeCache.txt\""
"\n then try again from another directory, e.g.:"
minor changes - remove some warnings - fix typos - cmake allow in-source build (when WITH_IN_SOURCE_BUILD is defined) - cmake, use an explicit list of rna files (don't glob)
2011-04-21 05:49:47 +00:00
"\n "
CMake: expand instructions for accidental 'cmake' run in source dir Our CMake setup refuses to run from the source directory (i.e. Blender does not support in-source builds). Instead, it shows instructions on how to clean up after an accidental `cmake` invocation. These instructions missed one directory that should also be removed (`CMakeFiles`), so that's been added to the message now. No functional changes to Blender or the build.
2021-10-26 10:45:55 +02:00
"\n rm -rf CMakeCache.txt CMakeFiles"
minor changes - remove some warnings - fix typos - cmake allow in-source build (when WITH_IN_SOURCE_BUILD is defined) - cmake, use an explicit list of rna files (don't glob)
2011-04-21 05:49:47 +00:00
"\n cd .."
"\n mkdir cmake-make"
"\n cd cmake-make"
"\n cmake ../blender"
"\n "
"\n Alternately define WITH_IN_SOURCE_BUILD to force this option (not recommended!)"
)
endif()
CMake: Give error on attempts to generate within the sources with instructions on how to do it out-of-source
2006-12-13 02:57:57 +00:00
endif()
Bump minimum CMake version to 3.10 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.
2020-07-28 14:17:13 +02:00
cmake_minimum_required(VERSION 3.10)
Revert "Increase CMake minimum version to 3.0" This reverts commit ff3cf93405e63fa367f64412bcfe96b382b24b38. Turns out distros only a year old still use CMake 2.8x
2015-11-10 02:52:29 +11:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
if(NOT EXECUTABLE_OUTPUT_PATH)
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
set(FIRST_RUN TRUE)
else()
set(FIRST_RUN FALSE)
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
endif()
add option WITH_BUILTIN_GLEW, so linux packagers can disable to use their own glew library.
2011-04-05 23:31:01 +00:00
# this starts out unset
fix [#27681] Python: crash assigning a 'set' to an array
2011-06-17 02:22:38 +00:00
list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build_files/cmake/Modules")
CMake: Move main platform checks to separate files Basically title says it all. The goal is to make platform maintenance easier, so you don't have to constantly scroll back and forth looking for if() branches to check which exact platform you're currently working on. Ideally we also would move option defaults to a platform files, but that i'm not sure how to implement in a nice way yet. Reviewers: mont29 Reviewed By: mont29 Differential Revision: https://developer.blender.org/D2148
2016-08-09 15:19:11 +02:00
list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build_files/cmake/platform")
add option WITH_BUILTIN_GLEW, so linux packagers can disable to use their own glew library.
2011-04-05 23:31:01 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# Avoid having an empty `CMAKE_BUILD_TYPE`.
CMake: Only set CMAKE_BUILD_TYPE_INIT when not set Convenience makefile now uses CMAKE_BUILD_TYPE_INIT, this means you can change the build type of an existing build and it won't be overwritten when running `make`. Useful if you want to add debug info to a release build for profiling.
2017-06-27 09:50:35 +10:00
if(NOT DEFINED CMAKE_BUILD_TYPE_INIT)
set(CMAKE_BUILD_TYPE_INIT "Release")
CMake: set compiler-ccache & build-type-init variables as advanced These settings aren't useful for basic configuration.
2021-02-10 17:42:31 +11:00
# Internal logic caches this variable, avoid showing it by default
# since it's easy to accidentally set instead of the build type.
CMake: Only set CMAKE_BUILD_TYPE_INIT when not set Convenience makefile now uses CMAKE_BUILD_TYPE_INIT, this means you can change the build type of an existing build and it won't be overwritten when running `make`. Useful if you want to add debug info to a release build for profiling.
2017-06-27 09:50:35 +10:00
endif()
CMake: always mark CMAKE_BUILD_TYPE_INIT as advanced When defined this wasn't marked as advanced.
2024-01-23 20:40:00 +11:00
mark_as_advanced(CMAKE_BUILD_TYPE_INIT)
initialize cmake's CMAKE_BUILD_TYPE to 'Release' add reference to cmake cache for convenience GNUMakefile
2011-06-27 13:18:08 +00:00
CMake: omit superfluous Up-to-date messages Causes a lot of noise when building the install target.
2018-07-30 15:20:34 +10:00
# Omit superfluous "Up-to-date" messages.
if(NOT DEFINED CMAKE_INSTALL_MESSAGE)
set(CMAKE_INSTALL_MESSAGE "LAZY")
endif()
minor changes to cmake, main noticable change is to disable RULE_MESSAGES which gives less output with makefiles (easier to spot warnings).
2010-06-07 14:28:37 +00:00
# quiet output for Makefiles, 'make -s' helps too
reverting own recent change to switch off RULE_MESSAGES since you cant see which files are rebuilding.
2010-06-09 06:21:07 +00:00
# set_property(GLOBAL PROPERTY RULE_MESSAGES OFF)
minor changes to cmake, main noticable change is to disable RULE_MESSAGES which gives less output with makefiles (easier to spot warnings).
2010-06-07 14:28:37 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
buildinfo is now quoted from the build systems, avoids stripping quotes on startup. tested with linux/cmake linux/scons windows/cmake/mingw windows/cmake/msvc
2011-08-22 12:24:14 +00:00
# Set policy
Revert "Increase CMake minimum version to 3.0" This reverts commit ff3cf93405e63fa367f64412bcfe96b382b24b38. Turns out distros only a year old still use CMake 2.8x
2015-11-10 02:52:29 +11:00
# see "cmake --help-policy CMP0003"
# So library linking is more sane
cmake_policy(SET CMP0003 NEW)
# So BUILDINFO and BLENDERPATH strings are automatically quoted
cmake_policy(SET CMP0005 NEW)
# So syntax problems are errors
cmake_policy(SET CMP0010 NEW)
# Input directories must have CMakeLists.txt
cmake_policy(SET CMP0014 NEW)
buildinfo is now quoted from the build systems, avoids stripping quotes on startup. tested with linux/cmake linux/scons windows/cmake/mingw windows/cmake/msvc
2011-08-22 12:24:14 +00:00
Cleanup: fix compiler warnings
2020-01-26 16:35:58 +01:00
# Silence draco warning on macOS, new policy works fine.
Fix CMake error with versions older than 3.9
2020-02-03 18:44:52 +01:00
if(POLICY CMP0068)
cmake_policy(SET CMP0068 NEW)
endif()
Cleanup: fix compiler warnings
2020-01-26 16:35:58 +01:00
CMake: Fix policy warning about OSL_ROOT being set. 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
2020-08-22 16:24:09 -06:00
# find_package() uses <PackageName>_ROOT variables.
if(POLICY CMP0074)
cmake_policy(SET CMP0074 NEW)
endif()
Fix upper-case package root CMake warning CMake 3.27 introduced the new policy CMP0144 which makes it so the find_Package() functions use the upper-case <package>_ROOT variable when set. It is off by default, but it does check for the possible interference and warns about it. The warning happens when the upper case package root variable is set, and a find_package() is called with a lower case package name. In practice this leads to issue with CMake on macOS where the TIFF_ROOT is set to an expected variable, and find_package is used to find TIFF. THe CMake's FindTIFF.cmake attempts to find CMake configuration of the tiff library using find_package(tiff CONFIG) which triggers the policy warning. This change makes it so the policy is set to NEW, silencing the warning and bringing us to a more desired/expected behavior. Pull Request: https://projects.blender.org/blender/blender/pulls/119120
2024-03-06 16:51:06 +01:00
# find_package() uses uppercase <PackageName>_ROOT variables.
if(POLICY CMP0144)
cmake_policy(SET CMP0144 NEW)
endif()
macOS: Portable builds with dynamic libraries. For Blender.app: dropping libomp.dylib next to Blender executable is enough for it getting picked up since `@executable_path` is an rpath. For non-distributed binaries datatoc, makesdna, tests etc, code for copying libomp.dylib to build folder is removed and replaced by CMake's rpath option for *build* tree. For bpy.so, the post build rpath change has also been replaced by CMake rpath option for *install* tree. Since -id has been changed in D11748, remove the `install_name_tool -change ...` command. Any dylib can just be dropped at `MAC_BLENDER_TARGET_DYLIBS_DIR` hereafter. Appending dylib path to `CMAKE_BUILD_RPATH` will be needed for datatoc etc if linked against one (instead of copying the dylibs around). Reviewed By: #platform_macos, brecht Differential Revision: https://developer.blender.org/D11997
2021-08-03 20:49:40 +05:30
# Install CODE|SCRIPT allow the use of generator expressions.
if(POLICY CMP0087)
cmake_policy(SET CMP0087 NEW)
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
GPU: GLSL compilation as C++ for gpu static shaders Allow compilation of shaders using C++ for linting and IDE support. Related #127983 Pull Request: https://projects.blender.org/blender/blender/pulls/128724
2024-11-12 18:53:34 +01:00
# Allow to specify language per file.
if(POLICY CMP0119)
cmake_policy(SET CMP0119 NEW)
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
CMake: enable CMP0177 policy to normalize desintion paths The deprecated functionality will be removed eventually, enable the new functionality.
2025-01-06 17:56:07 +11:00
# Install DESTINATION paths are normalized.
if(POLICY CMP0177)
cmake_policy(SET CMP0177 NEW)
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Load Blender's Local Macros
CMake changes - don't allow building if the LIBDIR is not found on mac/windows. - by default use -O2 rather then -O3 for GCC release flags, was crashing some GCC versions and blender releases are supposed to use -O2.
2011-05-23 14:56:14 +00:00
include(build_files/cmake/macros.cmake)
change in how cmake works with CMAKE_C_STANDARD_LIBRARIES / CMAKE_CXX_STANDARD_LIBRARIES. if not defined (first run) these are now set blank but can be defined later. the problem is that scons & cmake builds would link against different libraries since cmake added its own defaults. now, by default, scons & cmake have the same libraries. This fixes an obscure crash in MinGW where cmakes default linking with -ladvapi32 would crash on string formatting which used float precision as an argument, eg: printf("%.*f", 3, value); ...without giving a useful backtrace or pointing to the line of code doing the string formatting.
2011-04-09 11:16:37 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Initialize Project
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
CMake changes - don't allow building if the LIBDIR is not found on mac/windows. - by default use -O2 rather then -O3 for GCC release flags, was crashing some GCC versions and blender releases are supposed to use -O2.
2011-05-23 14:56:14 +00:00
blender_project_hack_pre()
change in how cmake works with CMAKE_C_STANDARD_LIBRARIES / CMAKE_CXX_STANDARD_LIBRARIES. if not defined (first run) these are now set blank but can be defined later. the problem is that scons & cmake builds would link against different libraries since cmake added its own defaults. now, by default, scons & cmake have the same libraries. This fixes an obscure crash in MinGW where cmakes default linking with -ladvapi32 would crash on string formatting which used float precision as an argument, eg: printf("%.*f", 3, value); ...without giving a useful backtrace or pointing to the line of code doing the string formatting.
2011-04-09 11:16:37 +00:00
CMake changes - don't allow building if the LIBDIR is not found on mac/windows. - by default use -O2 rather then -O3 for GCC release flags, was crashing some GCC versions and blender releases are supposed to use -O2.
2011-05-23 14:56:14 +00:00
project(Blender)
change in how cmake works with CMAKE_C_STANDARD_LIBRARIES / CMAKE_CXX_STANDARD_LIBRARIES. if not defined (first run) these are now set blank but can be defined later. the problem is that scons & cmake builds would link against different libraries since cmake added its own defaults. now, by default, scons & cmake have the same libraries. This fixes an obscure crash in MinGW where cmakes default linking with -ladvapi32 would crash on string formatting which used float precision as an argument, eg: printf("%.*f", 3, value); ...without giving a useful backtrace or pointing to the line of code doing the string formatting.
2011-04-09 11:16:37 +00:00
CMake changes - don't allow building if the LIBDIR is not found on mac/windows. - by default use -O2 rather then -O3 for GCC release flags, was crashing some GCC versions and blender releases are supposed to use -O2.
2011-05-23 14:56:14 +00:00
blender_project_hack_post()
change in how cmake works with CMAKE_C_STANDARD_LIBRARIES / CMAKE_CXX_STANDARD_LIBRARIES. if not defined (first run) these are now set blank but can be defined later. the problem is that scons & cmake builds would link against different libraries since cmake added its own defaults. now, by default, scons & cmake have the same libraries. This fixes an obscure crash in MinGW where cmakes default linking with -ladvapi32 would crash on string formatting which used float precision as an argument, eg: printf("%.*f", 3, value); ...without giving a useful backtrace or pointing to the line of code doing the string formatting.
2011-04-09 11:16:37 +00:00
import/export automated testing using CMake's CTest Will need to write full docs on this on the wiki. basic info. - 21 tests, OBJ/3DS/X3D/FBX, 3 tests per format import export. STL, PLY, BVH are TODO. - uses files in ../lib/tests (checkout separate) - run with CMake Makefiles "make test" or "ctest" - currently checks against basic MD5 hash on scene import and file MD5 hash on export (realize this wont work predictably on binary formats *TODO*). - currently uses a generic script for all tests with arguments to specify command to run, expected output, testing method, files to check against etc. Has already proved useful, found a number of bugs in import export and some in blender too.
2011-01-21 00:06:30 +00:00
enable_testing()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
# -----------------------------------------------------------------------------
# Test Compiler Support
#
Docs: Replace most wiki links with links to new developer docs 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
2024-01-18 16:10:52 +01:00
# Keep in sync with: https://developer.blender.org/docs/handbook/building_blender/
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
if(CMAKE_COMPILER_IS_GNUCC)
Build: bump minimum GCC version from 9.3.1 to 11.0.0 Increase the minimum version as part of the VFX platform 2023.
2022-12-17 13:53:30 +11:00
if("${CMAKE_C_COMPILER_VERSION}" VERSION_LESS "11.0.0")
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(FATAL_ERROR
"The minimum supported version of GCC is 11.0.0, found C compiler: "
"${CMAKE_C_COMPILER_VERSION}"
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
)
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
endif()
CMake: check both C & C++ compiler versions It was possible for an unsupported clang/gcc version to be used, this seems the likely cause of errors in #120879.
2024-04-26 17:59:20 +10:00
if("${CMAKE_CXX_COMPILER_VERSION}" VERSION_LESS "11.0.0")
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(FATAL_ERROR
"The minimum supported version of GCC is 11.0.0, found C++ compiler: "
"${CMAKE_CXX_COMPILER_VERSION}"
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
)
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
endif()
CMake: check both C & C++ compiler versions It was possible for an unsupported clang/gcc version to be used, this seems the likely cause of errors in #120879.
2024-04-26 17:59:20 +10:00
elseif(CMAKE_C_COMPILER_ID MATCHES "Clang")
if(CMAKE_COMPILER_IS_GNUCC)
if("${CMAKE_C_COMPILER_VERSION}" VERSION_LESS "8.0")
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(FATAL_ERROR
"The minimum supported version of CLANG is 8.0, found C compiler: "
"${CMAKE_C_COMPILER_VERSION}"
CMake: check both C & C++ compiler versions It was possible for an unsupported clang/gcc version to be used, this seems the likely cause of errors in #120879.
2024-04-26 17:59:20 +10:00
)
endif()
if("${CMAKE_CXX_COMPILER_VERSION}" VERSION_LESS "8.0")
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(FATAL_ERROR
"The minimum supported version of CLANG is 8.0, found C++ compiler: "
"${CMAKE_CXX_COMPILER_VERSION}"
CMake: check both C & C++ compiler versions It was possible for an unsupported clang/gcc version to be used, this seems the likely cause of errors in #120879.
2024-04-26 17:59:20 +10:00
)
endif()
endif()
Cleanup: use STREQUAL instead of MATCHES for exact comparisons MATCHES takes a REGEX and searches the input for a match, this isn't necessary for CMAKE_SYSTEM_PROCESSOR & CMAKE_*_COMPILER_ID.
2024-03-07 17:56:41 +11:00
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
if(MSVC_VERSION VERSION_LESS "1928")
CMake: when compiler is too old, report found version To aid in debugging the case where your compiler is too old for Blender, actually log which version CMake found. Before, CMake would output: ``` CMake Error at CMakeLists.txt:121 (message): The minimum supported version of GCC is 11.0.0 ``` With the patch, it logs: ``` CMake Error at CMakeLists.txt:121 (message): The minimum supported version of GCC is 11.0.0, found 10.4.0 ``` This has been implemented for GCC and Clang. MSVC has been explicitly excluded, as the version numbers used for this comparison are internal versions and not directly usable/recognisable. Reviewed By: LazyDodo, brecht Differential Revision: https://developer.blender.org/D16849
2023-01-05 11:34:11 +01:00
# MSVC_VERSION is an internal version number, it doesn't map to something
# the end user would recognize as a version. Because of this, for MSVC we do
# not show the found number. When using our make.bat the actual VS version
# will be displayed on the console before starting the build, anyway.
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
message(FATAL_ERROR "The minimum supported version of MSVC is 2019 (16.9.16)")
endif()
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Test Compiler/Library Features
CMake: support building with musl libc Instead of using macros like GLIBC we can use the CMake build systems internal functions to check if some header or functions are present on the running system's libc. Add ./build_files/cmake/have_features.cmake to add checks for platform features which can be used to set defines for source files that require them. Reviewed By: campbellbarton Ref D15696
2022-08-18 08:04:56 +10:00
include(build_files/cmake/have_features.cmake)
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Redirect Output Files
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
style cleanup: whitespace/indentation
2012-05-19 13:55:54 +00:00
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin CACHE INTERNAL "" FORCE)
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/lib CACHE INTERNAL "" FORCE)
Tests: set build directory using build type 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
2020-09-08 00:22:39 +05:30
get_property(GENERATOR_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(GENERATOR_IS_MULTI_CONFIG)
cmake/ctest: output test binaries to debug/release folders on windows. debug/release builds were writing the binaries to the same folder
2018-08-17 10:04:55 -06:00
set(TESTS_OUTPUT_DIR ${EXECUTABLE_OUTPUT_PATH}/tests/$<CONFIG>/ CACHE INTERNAL "" FORCE)
cmake: fix typo in else()
2018-08-17 14:14:26 -06:00
else()
cmake/ctest: output test binaries to debug/release folders on windows. debug/release builds were writing the binaries to the same folder
2018-08-17 10:04:55 -06:00
set(TESTS_OUTPUT_DIR ${EXECUTABLE_OUTPUT_PATH}/tests/ CACHE INTERNAL "" FORCE)
endif()
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Set Default Configuration Options
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
CMake patch from Ralf Hölzemer (cheleb) [#22849] Fix cmake install target on linux --- from the tracker --- This patch fixes the install target for the linux platform. Since the new configuration path changes are in effect, files have to be installed in the correct places instead of just copying the local installation to $PREFIX/share/blender. It also provides a new macro to determine the correct blender version values. Changes in this patch include: - the .desktop menu file is installed in $PREFIX/share/applications and points to the svg icon instead of a png one, which is also installed in $PREFIX/share/pixmaps - docs are installed in $PREFIX/share/doc/blender - scripts are installed in in $PREFIX/share/blender/x.xx/ - locales are installed in in $PREFIX/share/blender/x.xx/datafiles - a new cmake macro determines and sets the correct values for BLENDER_VERSION_MAJOR, BLENDER_VERSION_MINOR, BLENDER_SUBVERSION, BLENDER_VERSION, BLENDER_MINVERSION_MAJOR, BLENDER_MINVERSION_MINOR, BLENDER_MINSUBVERSION and BLENDER_MINVERSION by parsing source/blender/blenkernel/BKE_blender.h and calculating major/minor values. This replaces the hardcoded value in the top CMakeLists file and is used by all platforms.
2010-07-14 20:26:46 +00:00
get_blender_version()
UI: Updated Windows File Registration Windows file associations using ProgID, needed because of the launcher. This fixes "pin to taskbar" and Recent Documents lists, allow per- version jump lists and an "Open with" list with multiple versions. Pull Request: https://projects.blender.org/blender/blender/pulls/107013
2023-05-24 21:19:56 +02:00
if(WIN32)
add_definitions(
# This is the app ID used for file registration, given it's used from several modules
# there really is no nice way to get this information consistent without a global define.
-DBLENDER_WIN_APPID="blender.${BLENDER_VERSION_MAJOR}.${BLENDER_VERSION_MINOR}"
# This is the name that will be shown in the taskbar and OpenWith windows UI
-DBLENDER_WIN_APPID_FRIENDLY_NAME="Blender ${BLENDER_VERSION_MAJOR}.${BLENDER_VERSION_MINOR}"
)
endif()
CMake: disable some build option defaults T42569 This commit disables some lesser used dependencies for Linux/Unix systems by default. Run: `make full` to enabled options used in release build.
2014-11-13 23:32:01 +01:00
CMake: Enable CMAKE_OPTIMIZE_DEPENDENCIES by default Ever since #107858 landed builds of a single library from a clean state were significant heavier than they used to the since the full dependency chain is being build. While this is desired behavior since some projects emit artefacts (like bf_dna's dna_type_offsets.h) for others given we are building static libraries that don't actually get linked until the very end this is unneeded. CMake offers a flag here to optimize this called CMAKE_OPTIMIZE_DEPENDENCIES. See the CMake docs for details what this exactly does. This diff changes the default for CMAKE_OPTIMIZE_DEPENDENCIES from Off to On for all CMake versions that support it. If people desire to do so, this flag can still be changed though CMakeCache.txt Pull Request: https://projects.blender.org/blender/blender/pulls/109672
2023-07-04 17:38:02 +02:00
if(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.19")
# This changes the default value from Off to On, but will still allow people to manually change
# this setting through their CMakeCache.txt if they desire to do so.
set(CMAKE_OPTIMIZE_DEPENDENCIES ON CACHE INTERNAL "")
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Declare Options
CMake: correct own error using undefined var
2014-11-26 13:24:56 +01:00
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
# Blender internal features
Cleanup: remove references to the Blender Game Engine Player
2023-04-04 17:19:52 +10:00
option(WITH_BLENDER "Build blender (disable to build only Cycles stand-alone)." ON)
Advanced CMake option to build the player without blender: WITH_BLENDER
2011-07-13 08:15:06 +00:00
mark_as_advanced(WITH_BLENDER)
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
if(WIN32)
option(WITH_BLENDER_THUMBNAILER "\
Build \"BlendThumb.dll\" helper for Windows explorer integration to support extracting \
thumbnails from `.blend` files."
ON
)
macOS/QuickLook: support rich thumbnail in Finder Support thumbnail that shows the file contents instead of the default blend file icon for all files in Finder. Some files may still have the usual blender icon as thumbnail depending on their contents. blender-thumbnailer process is kept alive by the system in the background and is invoked by QuickLook when needed. The checkbox to disable the extension is present in the Settings app. It will NOT be an interactive "Preview" that allows richer interactions like Panning viewport, or rotating 3D objects.
2025-01-23 17:00:19 +01:00
elseif(UNIX AND NOT APPLE)
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
option(WITH_BLENDER_THUMBNAILER "\
Build stand-alone \"blender-thumbnailer\" command-line thumbnail extraction utility, \
intended for use by file-managers to extract PNG images from `.blend` files."
macOS/QuickLook: support rich thumbnail in Finder Support thumbnail that shows the file contents instead of the default blend file icon for all files in Finder. Some files may still have the usual blender icon as thumbnail depending on their contents. blender-thumbnailer process is kept alive by the system in the background and is invoked by QuickLook when needed. The checkbox to disable the extension is present in the Settings app. It will NOT be an interactive "Preview" that allows richer interactions like Panning viewport, or rotating 3D objects.
2025-01-23 17:00:19 +01:00
ON
)
elseif(APPLE)
option(WITH_BLENDER_THUMBNAILER "\
Xcode/thumbnailer: rebuild error due to rpath Fix duplicate rpath error on rebuild by using CMake target property. Pull Request: https://projects.blender.org/blender/blender/pulls/134527
2025-02-14 10:46:48 +01:00
Build \"blender-thumbnailer.appex\" extension for Finder/ QuickLook thumbnail \
support for blend files."
macOS/QuickLook: support rich thumbnail in Finder Support thumbnail that shows the file contents instead of the default blend file icon for all files in Finder. Some files may still have the usual blender icon as thumbnail depending on their contents. blender-thumbnailer process is kept alive by the system in the background and is invoked by QuickLook when needed. The checkbox to disable the extension is present in the Settings app. It will NOT be an interactive "Preview" that allows richer interactions like Panning viewport, or rotating 3D objects.
2025-01-23 17:00:19 +01:00
ON
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
)
CMake: add WITH_BLENDER_THUMBNAILER option Make building the thumbnail extraction executable optional, disable on macOS as this was not linking, further, macOS doesn't use this for thumbnail extraction so it could be left disabled.
2021-10-20 12:10:09 +11:00
endif()
when checking for windows check sys.platform starts with "win" rather then '== "win32"' & avoid importing platform. also add some notes to CMake options.
2011-03-11 01:24:16 +00:00
option(WITH_INTERNATIONAL "Enable I18N (International fonts and text)" ON)
CMake build option for security report: CVE-2009-3850 Nothing is changed by default but some linux distributions want to have executing python be opt-in. This keeps the same functionality but disables auto-run from factory settings and in background mode unless its enabled as a command line argument. This CMake option is marked as advanced and wont show in the regular options list so its less likely to be enabled by people that like to turn everything ON without reading descriptions :)
2011-04-28 06:20:47 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_PYTHON "Enable Embedded Python API (only disable for development)" ON)
Cleanup: trailing space in CMake files
2018-06-10 08:12:13 +02:00
option(WITH_PYTHON_SECURITY "Disables execution of scripts within blend files by default" ON)
Cleanup: cmake comment line length
2022-11-03 12:10:16 +11:00
# Don't want people disabling this unless they really know what they are doing.
mark_as_advanced(WITH_PYTHON)
# Some distributions see this as a security issue, rather than have them patch it,
# make a build option.
mark_as_advanced(WITH_PYTHON_SECURITY)
CMake build option for security report: CVE-2009-3850 Nothing is changed by default but some linux distributions want to have executing python be opt-in. This keeps the same functionality but disables auto-run from factory settings and in background mode unless its enabled as a command line argument. This CMake option is marked as advanced and wont show in the regular options list so its less likely to be enabled by people that like to turn everything ON without reading descriptions :)
2011-04-28 06:20:47 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_PYTHON_SAFETY "\
Enable internal API error checking to track invalid data to prevent crash on access \
(at the expense of some efficiency, only enable for development)."
OFF
)
CMake: mark lib/debug options advanced
2015-03-05 15:23:22 +11:00
mark_as_advanced(WITH_PYTHON_SAFETY)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_PYTHON_MODULE "\
Enable building as a python module which runs without a user interface, \
like running regular blender in background mode (only enable for development), \
installs to PYTHON_SITE_PACKAGES (or CMAKE_INSTALL_PREFIX if WITH_INSTALL_PORTABLE is enabled)."
OFF
)
WITH_PYTHON_FRAMEWORK cmake option for OSX This option allow Blender to be linked against the Framework python It's useful if you want to have blenderplayer and bpy in the same application and need to avoid PyThread problems. patch reviewed by Jens Verwiebe before 2.66. He may want to change something though. (also small: I changed: /Library/Frameworks/Python.framework/Versions//python by /Library/Frameworks/Python.framework/Versions//Python as the latter seems to be the norm)
2013-02-22 22:24:38 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_BUILDINFO "\
Include extra build details (only disable for development & faster builds)"
ON
)
set(BUILDINFO_OVERRIDE_DATE "" CACHE STRING "\
Use instead of the current date for reproducible builds (empty string disables this option)"
)
set(BUILDINFO_OVERRIDE_TIME "" CACHE STRING "\
Use instead of the current time for reproducible builds (empty string disables this option)"
)
set(CPACK_OVERRIDE_PACKAGENAME "" CACHE STRING "\
Use instead of the standard packagename (empty string disables this option)"
)
[cmake/cpack] allow override of package name Cpack generates a standard filename with git information in it, which might not always be wanted for release builds, this patch adds an option to override that default filename. Reviewers: sergey, juicyfruit Reviewed By: juicyfruit Differential Revision: https://developer.blender.org/D2199 ammended to fix: wrong variable name in main CMakeLists.txt
2016-09-06 07:21:23 -06:00
mark_as_advanced(CPACK_OVERRIDE_PACKAGENAME)
CMake: optional date/time overrides for reproducible builds
2016-05-11 02:43:58 +10:00
mark_as_advanced(BUILDINFO_OVERRIDE_DATE)
mark_as_advanced(BUILDINFO_OVERRIDE_TIME)
CMake: tweak so 2.8.7 and older still work (disable WITH_BUILDINFO)
2014-08-02 03:07:41 +10:00
CMake: Disable unity builds on cmake 2.28.2 CMake 2.28.2 has a regression that breaks the combination of precompiled headers and unity builds [1]. Disable unity builds for this specific cmake version to sidestep the issue. [1] https://gitlab.kitware.com/cmake/cmake/-/issues/25650
2024-02-01 09:09:20 -07:00
# CMAKE 3.28.2 has issues with the combination of PCH and unity builds, disable for now.
# upstream ticket https://gitlab.kitware.com/cmake/cmake/-/issues/25650
if(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.16" AND NOT ${CMAKE_VERSION} VERSION_EQUAL "3.28.2")
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_UNITY_BUILD "\
CMake: add warning for WITH_UNITY_BUILD
2023-08-11 09:34:07 +10:00
Enable unity build for modules that support it to improve compile times.\n\
WARNING: this option allows files to be built without all necessary headers!\n
This option should be disabled before manipulating or removing headers."
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
ON
)
CMake: add WITH_UNITY_BUILD option to improve compile times Unity builds are only used in the `bf_nodes_geometry` module for now. This module has been prepared to support unity builds already. Usually, there is a 2-4x speedup when building `bf_nodes_geometry` compared to without unity builds (e.g. 145s to 55s). For more information about how unity builds work and how they help with compile times, see D13341. Differential Revision: https://developer.blender.org/D13341
2021-11-24 11:40:26 +01:00
mark_as_advanced(WITH_UNITY_BUILD)
else()
set(WITH_UNITY_BUILD OFF)
endif()
CMake: add option to disable pre-compiled headers ./tools/utils_maintenance/code_clean failed to operate on any sources that used pre-compiled headers.
2024-02-21 10:35:20 +11:00
if(COMMAND target_precompile_headers)
# Disabling is needed for `./tools/utils_maintenance/code_clean.py` to function.
option(WITH_COMPILER_PRECOMPILED_HEADERS "\
Use pre-compiled headers to speed up compilation."
ON
)
mark_as_advanced(WITH_COMPILER_PRECOMPILED_HEADERS)
macOS: Add support for clang-tidy checks during compilation This commit adds support for clang-tidy checks during compilation on macOS, which can now be enabled using the optional `WITH_CLANG_TIDY` CMake variable. The clang-tidy executable doesn't need to be separately installed since CMake will pick up the executable from the LLVM pre-compiled library. This commit also expands the coverage of clang-tidy checks to Objective-C/C++, for which checks were enabled in PR #128334. Pull Request: https://projects.blender.org/blender/blender/pulls/129761
2024-11-13 16:14:01 +01:00
if(WITH_CLANG_TIDY AND (CMAKE_COMPILER_IS_GNUCC OR APPLE))
CMake: add option to disable pre-compiled headers ./tools/utils_maintenance/code_clean failed to operate on any sources that used pre-compiled headers.
2024-02-21 10:35:20 +11:00
if(WITH_COMPILER_PRECOMPILED_HEADERS)
message(STATUS
Cleanup: wrap long lines for CMake
2025-04-05 20:21:57 +11:00
"Clang-Tidy and the current compiler's precompiled headers are incompatible, "
"disabling precompiled headers."
CMake: add option to disable pre-compiled headers ./tools/utils_maintenance/code_clean failed to operate on any sources that used pre-compiled headers.
2024-02-21 10:35:20 +11:00
)
set(WITH_COMPILER_PRECOMPILED_HEADERS OFF)
endif()
endif()
if(NOT WITH_COMPILER_PRECOMPILED_HEADERS)
set(CMAKE_DISABLE_PRECOMPILE_HEADERS ON)
endif()
endif()
Build: Add WITH_OPTIMIZED_BUILD_TOOLS Enable optimizations on Debug builds for executables used for the build process (datatoc and glsl_preprocess) and enable unity builds for shader preprocessing targets. Debug: From 28.9s to 5.7s Release: From 4.9s to 3.5s Pull Request: https://projects.blender.org/blender/blender/pulls/138274
2025-05-02 18:33:44 +02:00
option(WITH_OPTIMIZED_BUILD_TOOLS "\
Enable optimizations even on Debug builds for executables used for the build process"
ON
)
mark_as_advanced(WITH_OPTIMIZED_BUILD_TOOLS)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_IK_ITASC "\
Enable ITASC IK solver (only disable for development & for incompatible C++ compilers)"
ON
)
option(WITH_IK_SOLVER "\
Enable Legacy IK solver (only disable for development)"
ON
)
Compositor: Optimize Fog Glow Glare node This patches optimizes the Fog Glow Glare node to be about 25x faster for 4K images. This is mainly achieved by utilizing the FFTW library and multi-threading support code. Further improvements are still possible by caching kernels, but the CPU compositor does not support caching yet. The old Hartley transform was removed, so the node no longer works when FFTW is disabled as a build time option, much like the OIDN node. A new BLI library was introduced for FFTW, it includes some helper routines relevant for FFTW as well as an initialization routine that sets up multithreading using TBB as well as thread safety. Build system support for threaded FFTW was also added, which defines the relevant variables to detect threading support as well as add the relevant libraries. We do not currently have the threaded FFTW libs in our precompiled libs, so the threading code is disabled until the libs lands in the coming weeks. So currently, the code is only about 9x faster. The only functional change is that the kernel is now odd sized, which should produce more accurate results, but the final result is almost identical and mostly undetectable. The plan is to port this to the GPU as well similar to how we implement OIDN until we have a GPU FFT implementation. GPU compositor can also do caching, so it should be faster, being able to compute a 4K image in under half a second. Pull Request: https://projects.blender.org/blender/blender/pulls/121653
2024-05-17 12:45:21 +02:00
option(WITH_FFTW3 "Enable FFTW3 support (Used for smoke, ocean sim, glare, and audio effects)" ON)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_PUGIXML "Enable PugiXML support (Used for OpenImageIO, Grease Pencil SVG export)" ON)
option(WITH_BULLET "Enable Bullet (Physics Engine)" ON)
option(WITH_SYSTEM_BULLET "\
Use the systems bullet library (currently unsupported due to missing features in upstream!)"
OFF
)
add option WITH_SYSTEM_BULLET to link against the bullet installation found on the system. Note: this doesn't work yet for everything with latest stable bullet (2.81), need to look into why and likely apply some patches upstream. However I managed to link blender by disabling some features, likely it can be made to work without too much trouble.
2013-01-03 00:23:52 +00:00
mark_as_advanced(WITH_SYSTEM_BULLET)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_OPENCOLORIO "Enable OpenColorIO color management" ON)
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
set(_option_default ON)
Build System: Add OpenXR-SDK dependency and WITH_XR_OPENXR build option The OpenXR-SDK contains utilities for using the OpenXR standard (https://www.khronos.org/openxr/). Namely C-headers and a so called "loader" to manage runtime linking to OpenXR platforms ("runtimes") installed on the user's system. The WITH_XR_OPENXR build option is disabled by default for now, as there is no code using it yet. On macOS it will remain disabled for now, it's untested and there's no OpenXR runtime in sight for it. Some points on the OpenXR-SDK dependency: * The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2). * Notes on updating the dependency: https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency * It contains a bunch of generated files, for which the sources are in a separate repository (https://github.com/KhronosGroup/OpenXR-SDK-Source). * We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features. * We currently use the OpenXR loader lib from it and the headers. * To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository. The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR with OpenEXR. Most of this comes from the 2019 GSoC project, "Core Support of Virtual Reality Headsets through OpenXR" (https://wiki.blender.org/wiki/User:Severin/GSoC-2019/). Differential Revision: https://developer.blender.org/D6188 Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray Molenkamp
2020-03-04 16:39:00 +01:00
if(APPLE)
# There's no OpenXR runtime in sight for macOS, neither is code well
# tested there -> disable it by default.
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
set(_option_default OFF)
endif()
option(WITH_XR_OPENXR "Enable VR features through the OpenXR specification" ${_option_default})
if(APPLE)
Build System: Add OpenXR-SDK dependency and WITH_XR_OPENXR build option The OpenXR-SDK contains utilities for using the OpenXR standard (https://www.khronos.org/openxr/). Namely C-headers and a so called "loader" to manage runtime linking to OpenXR platforms ("runtimes") installed on the user's system. The WITH_XR_OPENXR build option is disabled by default for now, as there is no code using it yet. On macOS it will remain disabled for now, it's untested and there's no OpenXR runtime in sight for it. Some points on the OpenXR-SDK dependency: * The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2). * Notes on updating the dependency: https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency * It contains a bunch of generated files, for which the sources are in a separate repository (https://github.com/KhronosGroup/OpenXR-SDK-Source). * We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features. * We currently use the OpenXR loader lib from it and the headers. * To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository. The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR with OpenEXR. Most of this comes from the 2019 GSoC project, "Core Support of Virtual Reality Headsets through OpenXR" (https://wiki.blender.org/wiki/User:Severin/GSoC-2019/). Differential Revision: https://developer.blender.org/D6188 Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray Molenkamp
2020-03-04 16:39:00 +01:00
mark_as_advanced(WITH_XR_OPENXR)
endif()
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
unset(_option_default)
Merge newboolean branch into master. 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.
2020-08-28 10:56:44 -04:00
option(WITH_GMP "Enable features depending on GMP (Exact Boolean)" ON)
Modeling: Add a new boolean solver based on the Manifold library. Adds the 'manifold' solver option to the Boolean geo node and to the Boolean modifier. This solver is about as fast, or faster, than the current float solver, and is robust against floating point issues like the Exact solver. But currently it only works on mesh arguments that are strictly manifold. See https://projects.blender.org/blender/blender/issues/120182 for many more details.
2025-04-22 21:23:37 -04:00
option(WITH_MANIFOLD "Enable features depending on Manifold (Fast Robust Boolean)" ON)
CMake: Add option to enable -Werror cflag in some areas It is rather annoying attitude nowadays to use const qualifier all over the place, including using it for multi-dimensional arrays. This isn't really supported in GCC prior to version 5.0 because it considers such an arrays to be a "pointer to a const pointer" which gives implicit casting errors. It's not possible to disable this particular type of warnings treated as errors in any GCC version prior to 5.0 as well, meaning currently usage of -Werror globally in Blender code is not possible at all. This commit makes it possible to use -Werror in areas which are complaint with older GCC versions. New advanced CMake options are: - WITH_COMPOSITOR_WERROR - WITH_LIBMV_WERROR - WITH_CYCLES_WERROR
2015-07-18 10:35:03 +02:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_OPENIMAGEDENOISE "Enable the OpenImageDenoise compositing node" ON)
CMake option 'WITH_HEADLESS' to build blender in headless mode (no x11/xlib) with NULL ghost classe.
2011-06-04 14:12:55 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_OPENSUBDIV "Enable OpenSubdiv for surface subdivision" ON)
OpenSubdiv: Commit of OpenSubdiv integration into Blender This commit contains all the remained parts needed for initial integration of OpenSubdiv into Blender's subdivision surface code. Includes both GPU and CPU backends which works in the following way: - When SubSurf modifier is the last in the modifiers stack then GPU pipeline of OpenSubdiv is used, making viewport performance as fast as possible. This also requires graphscard with GLSL 1.5 support. If this requirement is not met, then no GPU pipeline is used at all. - If SubSurf is not a last modifier or if DerivesMesh is being evaluated for rendering then CPU limit evaluation API from OpenSubdiv is used. This only replaces the legacy evaluation code from CCGSubSurf_legacy, but keeps CCG structures exactly the same as they used to be for ages now. This integration is fully covered with ifdef and not enabled by default because there are several TODOs to be solved first: - Face varying data interpolation is not really cleanly implemented for GPU in OpenSubdiv 3.0. It is also not implemented for limit evaluation API. This basically means we'll have really hard time supporting UVs. - Limit evaluation only works with adaptivly subdivided meshes so far, which basically means all the points of CCG are pushed to the limit. This gives different result from old code. - There are some serious optimizations possible on the topology refiner creation, which would speed up initial OpenSubdiv mesh creation. - There are some hardcoded asumptions in the GPU and DerivedMesh areas which could be generalized. That's something where Antony and Campbell can help, making it so the code is structured in a way which is reusable by all planned viewport projects. - There are also some workarounds in the dependency graph to make sure OpenGL buffers are only freed from the main thread. Those who'll be wanting to make experiments with this code should grab dev branch (NOT master) from https://github.com/Nazg-Gul/OpenSubdiv/tree/dev There are some patches applied in there which we're working on on getting into upstream.
2015-07-20 16:08:06 +02:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_POTRACE "Enable features relying on potrace" ON)
option(WITH_OPENVDB "Enable features relying on OpenVDB" ON)
option(WITH_OPENVDB_BLOSC "\
Enable blosc compression for OpenVDB, only enable if OpenVDB was built with blosc support"
ON
)
option(WITH_OPENVDB_3_ABI_COMPATIBLE "\
Assume OpenVDB library has been compiled with version 3 ABI compatibility"
OFF
)
Build: add WITH_OPENVDB_3_ABI_COMPATIBLE option. Better fix for T54457. It seems Debian compiles OpenVDB without ABI 3 compatibility, while Arch does enable it as is the default in the OpeVDB CMake build system. So now there's an option that the distribution can set depending on how they compile their OpenVDB package.
2018-04-02 18:55:10 +02:00
mark_as_advanced(WITH_OPENVDB_3_ABI_COMPATIBLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_NANOVDB "Enable usage of NanoVDB data structure for rendering on the GPU" ON)
option(WITH_HARU "Enable features relying on Libharu (Grease pencil PDF export)" ON)
Implementation of OpenVDB as a possible cache format for smoke simulations. This commits implements OpenVDB as an extra cache format in the Point Cache system for smoke simulations. Compilation with the library is turned off by default for now, and shall be enabled when the library is present. A documentation of its doings is available here: http:// wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport. A guide to compile OpenVDB can be found here (Linux): http:// wiki.blender.org/index.php?title=Dev:Doc/Building_Blender/Linux/ Dependencies_From_Source#OpenVDB Reviewers: sergey, lukastoenne, brecht, campbellbarton Reviewed By: brecht, campbellbarton Subscribers: galenb, Blendify, robocyte, Lapineige, bliblubli, jtheninja, lukasstockner97, dingto, brecht Differential Revision: https://developer.blender.org/D1721
2016-01-23 08:39:29 +01:00
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
# GHOST Windowing Library Options
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_GHOST_DEBUG "Enable debugging output for the GHOST library" OFF)
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
mark_as_advanced(WITH_GHOST_DEBUG)
cmake option to build without an audio library.
2011-06-23 09:27:56 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_GHOST_SDL "\
Enable building Blender against SDL for windowing rather than the native APIs"
OFF
)
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
mark_as_advanced(WITH_GHOST_SDL)
build option to use SDL 1.3 for GHOST rather then X11/Win32/Cocoa api's, This opens up the option for blender to be more easily ported to other devices, OS's. TODO - continuous grab. - text glitch with multiple windows (was a bug in X11 too for a while, will check on this)
2011-07-12 13:17:54 +00:00
CMake: add WITH_GHOST_X11 option - Support building only with Wayland. - In this case, show useful error messages when Wayland fails to load.
2020-05-01 20:07:01 +10:00
if(UNIX AND NOT (APPLE OR HAIKU))
option(WITH_GHOST_X11 "Enable building Blender against X11 for windowing" ON)
mark_as_advanced(WITH_GHOST_X11)
Linux: enable WAYLAND by default Enable the following CMake options: - WITH_GHOST_WAYLAND Enable Wayland which is now included as part the bundled dependencies. When the pre-compiled libraries aren't used, only X11 will be enabled. - WITH_GHOST_WAYLAND_DYNLOAD So systems without libwayland can fall back to X11. - WITH_GHOST_WAYLAND_LIBDECOR To draw window frames on WAYLAND compositors such as gnome-shell which expect client-side decorations (without this the Blender window is borderless). Unfortunately there doesn't seem to be a reliable way to know if the compositors handles server-side decorations, so libdecor is required for Wayland to be used even with KDE and tiling compositors where it's not needed. Although this is an area that could use some further investigation - possibly bundling libdecor or handling client-side decorations in Blender. The final part of D16091.
2022-10-08 08:05:46 +11:00
option(WITH_GHOST_WAYLAND "Enable building Blender against Wayland for windowing" ON)
CMake: add WITH_GHOST_X11 option - Support building only with Wayland. - In this case, show useful error messages when Wayland fails to load.
2020-05-01 20:07:01 +10:00
mark_as_advanced(WITH_GHOST_WAYLAND)
GHOST/Wayland: support client-side window decorations This implements client-side window decorations for moving and resizing windows and HiDPI support. This functionality depends on the external project 'libdecor' that is currently a build option: WITH_GHOST_WAYLAND_LIBDECOR. Reviewed by: brecht, campbellbarton Ref D7989
2022-06-24 16:10:20 +10:00
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
if(WITH_GHOST_WAYLAND)
Linux: enable WAYLAND by default Enable the following CMake options: - WITH_GHOST_WAYLAND Enable Wayland which is now included as part the bundled dependencies. When the pre-compiled libraries aren't used, only X11 will be enabled. - WITH_GHOST_WAYLAND_DYNLOAD So systems without libwayland can fall back to X11. - WITH_GHOST_WAYLAND_LIBDECOR To draw window frames on WAYLAND compositors such as gnome-shell which expect client-side decorations (without this the Blender window is borderless). Unfortunately there doesn't seem to be a reliable way to know if the compositors handles server-side decorations, so libdecor is required for Wayland to be used even with KDE and tiling compositors where it's not needed. Although this is an area that could use some further investigation - possibly bundling libdecor or handling client-side decorations in Blender. The final part of D16091.
2022-10-08 08:05:46 +11:00
option(WITH_GHOST_WAYLAND_LIBDECOR "Optionally build with LibDecor window decorations" ON)
GHOST/Wayland: support client-side window decorations This implements client-side window decorations for moving and resizing windows and HiDPI support. This functionality depends on the external project 'libdecor' that is currently a build option: WITH_GHOST_WAYLAND_LIBDECOR. Reviewed by: brecht, campbellbarton Ref D7989
2022-06-24 16:10:20 +10:00
mark_as_advanced(WITH_GHOST_WAYLAND_LIBDECOR)
GHOST/Wayland: Add a build time option for DBUS, disable by default Add WITH_GHOST_WAYLAND_DBUS option, so Blender can be built without DBUS support. Currently it's only used to access the cursor theme. Without this the "default" cursors are used instead. Disabling this since it adds an additional dependency for a minor gain in functionality, with the benefit of removing a library requirement. There is also a problem where Blender hangs on startup for ~5 seconds when DBUS isn't running. Eventually it would be good to be able to avoid this problem without a build option.
2022-06-27 16:33:58 +10:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_GHOST_WAYLAND_DYNLOAD "Enable runtime dynamic WAYLAND libraries loading" ON)
GHOST/Wayland: support dynamic loading libraries for Wayland Add intern/wayland_dynload which is used when WITH_GHOST_WAYLAND_DYNLOAD is enabled (off by default). When enabled, systems without Wayland installed will fall back to X11. This allows Blender to dynamically load: - libwayland-client - libwayland-cursor - libwayland-egl - libdecor-0 (when WITH_GHOST_WAYLAND_LIBDECOR is enabled).
2022-07-05 14:49:36 +10:00
mark_as_advanced(WITH_GHOST_WAYLAND_DYNLOAD)
GHOST/Wayland: add build option to set the XDG app-id Add WITH_GHOST_WAYLAND_APP_ID so people making custom builds may differentiate the blender instance by version/branch etc.
2022-11-16 11:15:10 +11:00
set(WITH_GHOST_WAYLAND_APP_ID "" CACHE STRING "\
The application ID used for Blender (use default when an empty string), \
this can be used to differentiate Blender instances by version or branch for example."
)
mark_as_advanced(WITH_GHOST_WAYLAND_APP_ID)
GHOST/Wayland: support client-side window decorations This implements client-side window decorations for moving and resizing windows and HiDPI support. This functionality depends on the external project 'libdecor' that is currently a build option: WITH_GHOST_WAYLAND_LIBDECOR. Reviewed by: brecht, campbellbarton Ref D7989
2022-06-24 16:10:20 +10:00
endif()
GHOST: initial Wayland support Usable with the CMake option 'WITH_GHOST_WAYLAND' The following functionality is working: - Building with X11 and Wayland at the same time, wayland is used when available. - Keyboard, pointer handling. - Cursor handling. - Dedicated off-screen windows. - Drag & drop. - Copy & paste. - Pointer grabbing. See D6567 for further details.
2020-04-30 13:46:42 +10:00
endif()
Cleanup: rename WITH_X11 to WITH_GHOST_X11 Matches WITH_GHOST_{SDL|WAYLAND}
2020-05-01 19:14:50 +10:00
if(WITH_GHOST_X11)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_GHOST_XDND "Enable drag'n'drop support on X11 using XDND protocol" ON)
CMake: remove deprecated mudflap option
2014-11-13 19:43:15 +01:00
endif()
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
# Misc...
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_HEADLESS "Build without graphical support (renderfarm, server mode only)" OFF)
CMake option 'WITH_HEADLESS' to build blender in headless mode (no x11/xlib) with NULL ghost classe.
2011-06-04 14:12:55 +00:00
mark_as_advanced(WITH_HEADLESS)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_QUADRIFLOW "Build with quadriflow remesher support" ON)
Add QuadriFlow remesher
2019-08-26 18:34:11 +02:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_AUDASPACE "\
Build with blenders audio library (only disable if you know what you're doing!)"
ON
)
option(WITH_SYSTEM_AUDASPACE "\
Build with external audaspace library installed on the system \
(only enable if you know what you're doing!)"
OFF
)
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
mark_as_advanced(WITH_AUDASPACE)
Audaspace: fixing problems for the merge to master suggested by Campbell and Sergey. - rename WITH_EXTERNAL_AUDASPACE to WITH_SYSTEM_AUDASPACE. - rename C/PYAUDASPACE to AUDASPACE_C/PY - simplifying cmake defines and includes. - fixing include paths and enabling WITH_SYSTEM_AUDASPACE for windows. - fixing scons building. - other minor build system fixes.
2015-06-16 10:03:35 +02:00
mark_as_advanced(WITH_SYSTEM_AUDASPACE)
CMake: issue warnings when changing options Only done in top level CMakeLists, and platform_apple. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D10343
2021-03-30 20:28:45 +05:30
set_and_warn_dependency(WITH_AUDASPACE WITH_SYSTEM_AUDASPACE OFF)
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
Cleanup: rename WITH_X11 to WITH_GHOST_X11 Matches WITH_GHOST_{SDL|WAYLAND}
2020-05-01 19:14:50 +10:00
if(WITH_GHOST_X11)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_X11_XINPUT "Enable X11 Xinput (tablet support and unicode input)" ON)
option(WITH_X11_XFIXES "Enable X11 XWayland cursor warping workaround" ON)
Ghost Context Refactor https://developer.blender.org/D643 Separates graphics context creation from window code in Ghost so that they can vary separately.
2014-10-07 15:46:19 -05:00
endif()
Revert "GHOST/X11: enable EGL" This is causing issues for some users launching Blender, because EGL indirectly requires GLVND, which is not installed by default on e.g. Ubuntu. This reverts commit 0b18a618b88b22663e05eca0f4d976875710e7cc. Fixes T90374 Ref D12034
2021-08-02 17:15:53 +02:00
if(UNIX AND NOT APPLE)
CMake: add WITH_SYSTEM_FREETYPE to link against the systems freetype
2022-01-26 15:30:21 +11:00
option(WITH_SYSTEM_FREETYPE "Use the freetype library provided by the operating system" OFF)
Build: when using Wayland, always enable EGL and disable system GLEW GLEW does not support GLX and EGL at the same time, and the distribution version is likely to have GLX. This also refactors the code so all OpenGL related CMake options are together. Differential Revision: https://developer.blender.org/D12034
2022-06-23 18:51:12 +02:00
option(WITH_SYSTEM_EIGEN3 "Use the systems Eigen3 library" OFF)
Revert "GHOST/X11: enable EGL" This is causing issues for some users launching Blender, because EGL indirectly requires GLVND, which is not installed by default on e.g. Ubuntu. This reverts commit 0b18a618b88b22663e05eca0f4d976875710e7cc. Fixes T90374 Ref D12034
2021-08-02 17:15:53 +02:00
else()
CMake: add WITH_SYSTEM_FREETYPE to link against the systems freetype
2022-01-26 15:30:21 +11:00
set(WITH_SYSTEM_FREETYPE OFF)
Build: when using Wayland, always enable EGL and disable system GLEW GLEW does not support GLX and EGL at the same time, and the distribution version is likely to have GLX. This also refactors the code so all OpenGL related CMake options are together. Differential Revision: https://developer.blender.org/D12034
2022-06-23 18:51:12 +02:00
set(WITH_SYSTEM_EIGEN3 OFF)
CMake: unbundle eigen3 Optionally use systems eigen3 library. T41989 by @hasufell with edits
2015-03-19 15:41:41 +11:00
endif()
Creator: Add CPU check on startup This adds an sse42 cpu check on startup for both linux and windows, mac has been excluded, since there are no intel based macs that do not support SSE42. The way this works is, we count on the OS to initialize the shared libraries in the order they are linked (which currently holds true) before calling the initialization code in the main executable. This allows us to check the CPU before running any of the code in the main executable that might not be supported by the current isa. Changing those build flags is for a future PR, but for now and for future reference: blender_cpu_check must be build without optimized CPU flags so it'll be able to run on older CPUs. some code has been duplicated from blenlib, there's really no way around that since we cannot link blenlib as it may be build with optimized cpu flags. Windows currently gives a popup to inform the user, while linux reports to the console, there may be better ways to communicate with linux users with perhaps some generic GUI popup, but I'm unaware of these and will leave this for the linux platform maintainer to polish. Part of #116592 Pull Request: https://projects.blender.org/blender/blender/pulls/118054
2024-02-19 18:11:57 +01:00
if((NOT WITH_PYTHON_MODULE) AND (
(WIN32 AND (CMAKE_SYSTEM_PROCESSOR STREQUAL "AMD64")) OR
((UNIX AND NOT APPLE) AND (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64"))))
option(WITH_CPU_CHECK "\
Report when a CPU is not compatible on startup \
instead of failing to start with an inscrutable error."
ON
)
mark_as_advanced(WITH_CPU_CHECK)
else()
set(WITH_CPU_CHECK OFF)
endif()
add cmake option WITH_SYSTEM_OPENJPEG so linux can build cycles without having libopenjpeg installed.
2012-06-23 14:23:44 +00:00
CMake options to disable Decimate and Boolean Modifiers: WITH_MOD_BOOLEAN, WITH_MOD_DECIMATE, renamed WITH_FLUID to WITH_MOD_FLUID
2010-10-23 15:40:13 +00:00
# Modifiers
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_MOD_FLUID "Enable Mantaflow Fluid Simulation Framework" ON)
option(WITH_MOD_REMESH "Enable Remesh Modifier" ON)
option(WITH_MOD_OCEANSIM "Enable Ocean Modifier" ON)
CMake options to disable Decimate and Boolean Modifiers: WITH_MOD_BOOLEAN, WITH_MOD_DECIMATE, renamed WITH_FLUID to WITH_MOD_FLUID
2010-10-23 15:40:13 +00:00
UV: add support for the SLIM unwrapping algorithm Integrate an existing implementation of the SLIM unwrapping algorithm into Blender. More info about SLIM here: https://igl.ethz.ch/projects/slim/ This commit is based on the integration code written by Aurel Gruber for Blender 2.7x (unfinished and never merged with the main branch). This commit is based on Aurel's code, rebased and further improved. Details: - Unwrap has been moved into a sub-menu, slim unwrapping is exposed as: "Minimum Stretch". - Live unwrap with SLIM refines the solutions using a timer. - When using SLIM there are options to: - Set the number of iterations. - Weight the influence using vertex weights. - SLIM can be disabled using the `WITH_UV_SLIM` build option. Co-authored-by: Aurel Gruber <aurel.gruber@infix.ch> Ref !114545
2024-09-21 11:16:06 +10:00
# UV solvers.
option(WITH_UV_SLIM "SLIM UV unwrapping solver" ON)
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
# Image format support
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_IMAGE_OPENEXR "Enable OpenEXR Support (http://www.openexr.com)" ON)
option(WITH_IMAGE_OPENJPEG "Enable OpenJpeg Support (http://www.openjpeg.org)" ON)
option(WITH_IMAGE_CINEON "Enable CINEON and DPX Image Support" ON)
option(WITH_IMAGE_WEBP "Enable WebP Image Support" ON)
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
Add option for CMake to build libredcode, also use CODEC prefix for ffmpeg, quicktime & sndfile options.
2010-11-30 18:52:39 +00:00
# Audio/Video format support
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CODEC_FFMPEG "Enable FFMPeg Support (http://ffmpeg.org)" ON)
option(WITH_CODEC_SNDFILE "Enable libsndfile Support (http://www.mega-nerd.com/libsndfile)" ON)
CMake OS X: enable FFMPEG and Quicktime by default to match release and scons.
2013-11-17 09:23:18 +01:00
Basic Alembic support All in all, this patch adds an Alembic importer, an Alembic exporter, and a new CacheFile data block which, for now, wraps around an Alembic archive. This data block is made available through a new modifier ("Mesh Sequence Cache") as well as a new constraint ("Transform Cache") to somewhat properly support respectively geometric and transformation data streaming from alembic caches. A more in-depth documentation is to be found on the wiki, as well as a guide to compile alembic: https://wiki.blender.org/index.php/ User:Kevindietrich/AlembicBasicIo. Many thanks to everyone involved in this little project, and huge shout out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the custom builds and compile fixes. Reviewers: sergey, campbellbarton, mont29 Reviewed By: sergey, campbellbarton, mont29 Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
# Alembic support
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_ALEMBIC "Enable Alembic Support" ON)
Basic Alembic support All in all, this patch adds an Alembic importer, an Alembic exporter, and a new CacheFile data block which, for now, wraps around an Alembic archive. This data block is made available through a new modifier ("Mesh Sequence Cache") as well as a new constraint ("Transform Cache") to somewhat properly support respectively geometric and transformation data streaming from alembic caches. A more in-depth documentation is to be found on the wiki, as well as a guide to compile alembic: https://wiki.blender.org/index.php/ User:Kevindietrich/AlembicBasicIo. Many thanks to everyone involved in this little project, and huge shout out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the custom builds and compile fixes. Reviewers: sergey, campbellbarton, mont29 Reviewed By: sergey, campbellbarton, mont29 Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
USD: Introducing a simple USD Exporter This commit introduces the first version of an exporter to Pixar's Universal Scene Description (USD) format. Reviewed By: sergey, LazyDodo Differential Revision: https://developer.blender.org/D6287 - The USD libraries are built by `make deps`, but not yet built by install_deps.sh. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - The way materials and UV coordinates and Normals are exported is going to change soon. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == Support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See https://github.com/PixarAnimationStudios/USD/issues/542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. Materials are exported as a flat list under a top-level '/_materials' namespace. This inhibits instancing of the objects using those materials, so this is subject to change. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard. == The Building Process == - USD is built as monolithic library, instead of 25 smaller libraries. We were linking all of them as 'whole archive' anyway, so this doesn't affect the final file size. It does, however, make life easier with respect to linking order, and handling upstream changes. - The JSON files required by USD are installed into datafiles/usd; they are required on every platform. Set the `PXR_PATH_DEBUG` to any value to have the USD library print the paths it uses to find those files. - USD is patched so that it finds the aforementioned JSON files in a path that we pass to it from Blender. - USD is patched to have a `PXR_BUILD_USD_TOOLS` CMake option to disable building the tools in its `bin` directory. This is sent as a pull request at https://github.com/PixarAnimationStudios/USD/pull/1048
2019-12-13 10:27:40 +01:00
# Universal Scene Description support
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_USD "Enable Universal Scene Description (USD) Support" ON)
USD: Introducing a simple USD Exporter This commit introduces the first version of an exporter to Pixar's Universal Scene Description (USD) format. Reviewed By: sergey, LazyDodo Differential Revision: https://developer.blender.org/D6287 - The USD libraries are built by `make deps`, but not yet built by install_deps.sh. - Only experimental support for instancing; by default all duplicated objects are made real in the USD file. This is fine for exporting a linked-in posed character, not so much for thousands of pebbles etc. - The way materials and UV coordinates and Normals are exported is going to change soon. - This patch contains LazyDodo's fixes for building on Windows in D5359. == Meshes == USD seems to support neither per-material nor per-face-group double-sidedness, so we just use the flag from the first non-empty material slot. If there is no material we default to double-sidedness. Each UV map is stored on the mesh in a separate primvar. Materials can refer to these UV maps, but this is not yet exported by Blender. The primvar name is the same as the UV Map name. This is to allow the standard name "st" for texture coordinates by naming the UV Map as such, without having to guess which UV Map is the "standard" one. Face-varying mesh normals are written to USD. When the mesh has custom loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is inspected to determine the normals. The UV maps and mesh normals take up a significant amount of space, so exporting them is optional. They're still enabled by default, though. For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported with UVs and normals, and 262 MiB without. We probably have room for optimisation of written UVs and normals. The mesh subdivision scheme isn't using the default value 'Catmull Clark', but uses 'None', indicating we're exporting a polygonal mesh. This is necessary for USD to understand our normals; otherwise the mesh is always rendered smooth. In the future we may want to expose this choice of subdivision scheme to the user, or auto-detect it when we actually support exporting pre-subdivision meshes. A possible optimisation could be to inspect whether all polygons are smooth or flat, and mark the USD mesh as such. This can be added when needed. == Animation == Mesh and transform animation are now written when passing `animation=True` to the export operator. There is no inspection of whether an object is actually animated or not; USD can handle deduplication of static values for us. The administration of which timecode to use for the export is left to the file-format-specific concrete subclasses of `AbstractHierarchyIterator`; the abstract iterator itself doesn't know anything about the passage of time. This will allow subclasses for the frame-based USD format and time-based Alembic format. == Support for simple preview materials == Very simple versions of the materials are now exported, using only the viewport diffuse RGB, metallic, and roughness. When there are multiple materials, the mesh faces are stored as geometry subset and each material is assigned to the appropriate subset. If there is only one material this is skipped. The first material if any) is always applied to the mesh itself (regardless of the existence of geometry subsets), because the Hydra viewport doesn't support materials on subsets. See https://github.com/PixarAnimationStudios/USD/issues/542 for more info. Note that the geometry subsets are not yet time-sampled, so it may break when an animated mesh changes topology. Materials are exported as a flat list under a top-level '/_materials' namespace. This inhibits instancing of the objects using those materials, so this is subject to change. == Hair == Only the parent strands are exported, and only with a constant colour. No UV coordinates, no information about the normals. == Camera == Only perspective cameras are supported for now. == Particles == Particles are only written when they are alive, which means that they are always visible (there is currently no code that deals with marking them as invisible outside their lifespan). Particle-system-instanced objects are exported by suffixing the object name with the particle's persistent ID, giving each particle XForm a unique name. == Instancing/referencing == This exporter has experimental support for instancing/referencing. Dupli-object meshes are now written to USD as references to the original mesh. This is still very limited in correctness, as there are issues referencing to materials from a referenced mesh. I am still committing this, as it gives us a place to start when continuing the quest for proper instancing in USD. == Lights == USD does not directly support spot lights, so those aren't exported yet. It's possible to add this in the future via the UsdLuxShapingAPI. The units used for the light intensity are also still a bit of a mystery. == Fluid vertex velocities == Currently only fluid simulations (not meshes in general) have explicit vertex velocities. This is the most important case for exporting velocities, though, as the baked mesh changes topology all the time, and thus computing the velocities at import time in a post-processing step is hard. == The Building Process == - USD is built as monolithic library, instead of 25 smaller libraries. We were linking all of them as 'whole archive' anyway, so this doesn't affect the final file size. It does, however, make life easier with respect to linking order, and handling upstream changes. - The JSON files required by USD are installed into datafiles/usd; they are required on every platform. Set the `PXR_PATH_DEBUG` to any value to have the USD library print the paths it uses to find those files. - USD is patched so that it finds the aforementioned JSON files in a path that we pass to it from Blender. - USD is patched to have a `PXR_BUILD_USD_TOOLS` CMake option to disable building the tools in its `bin` directory. This is sent as a pull request at https://github.com/PixarAnimationStudios/USD/pull/1048
2019-12-13 10:27:40 +01:00
Build: library updates for Blender 3.5 This updates the libraries dependencies for VFX platform 2023, and adds various new libraries. It also enables Python bindings and switches from static to shared for various libraries. The precompiled libraries for all platforms will be updated to these new versions in the coming weeks. New: Fribidi 1.0.12 Harfbuzz 5.1.0 MaterialX 1.38.6 (shared lib with python bindings) Minizipng 3.0.7 Pybind11 2.10.1 Shaderc 2022.3 Vulkan 1.2.198 Updated: Boost 1.8.0 (shared lib) Cython 0.29.30 Numpy 1.23.2 OpenColorIO 2.2.0 (shared lib with python bindings) OpenImageIO 2.4.6.0 (shared lib with python bindings) OpenSubdiv 3.5.0 OpenVDB 10.0.0 (shared lib with python bindings) OSL 1.12.7.1 (enable nvptx backend) TBB (shared lib) USD 22.11 (shared lib with python bindings, enable hydra) yaml-cpp 0.8.0 Includes contributions by Ray Molenkamp, Brecht Van Lommel, Georgiy Markelov and Campbell Barton. Ref T99618
2022-12-05 23:18:54 +01:00
# MaterialX
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_MATERIALX "Enable MaterialX Support" ON)
Build: library updates for Blender 3.5 This updates the libraries dependencies for VFX platform 2023, and adds various new libraries. It also enables Python bindings and switches from static to shared for various libraries. The precompiled libraries for all platforms will be updated to these new versions in the coming weeks. New: Fribidi 1.0.12 Harfbuzz 5.1.0 MaterialX 1.38.6 (shared lib with python bindings) Minizipng 3.0.7 Pybind11 2.10.1 Shaderc 2022.3 Vulkan 1.2.198 Updated: Boost 1.8.0 (shared lib) Cython 0.29.30 Numpy 1.23.2 OpenColorIO 2.2.0 (shared lib with python bindings) OpenImageIO 2.4.6.0 (shared lib with python bindings) OpenSubdiv 3.5.0 OpenVDB 10.0.0 (shared lib with python bindings) OSL 1.12.7.1 (enable nvptx backend) TBB (shared lib) USD 22.11 (shared lib with python bindings, enable hydra) yaml-cpp 0.8.0 Includes contributions by Ray Molenkamp, Brecht Van Lommel, Georgiy Markelov and Campbell Barton. Ref T99618
2022-12-05 23:18:54 +01:00
Render: support USD Hydra render delegates Hydra is a rendering architecture part of USD, designed to abstract the host application from the renderer. A renderer implementing a Hydra render delegate can run in any host application supporting Hydra, which now includes Blender. For external renderers this means less code to be written, and improved performance due to a using a C++ API instead of a Python API. Add-ons need to subclass bpy.types.HydraRenderEngine. See the example in the Python API docs for details. An add-on for Hydra Storm will be included as well. This is USD's rasterizing renderer, used in other applications like usdview. For users it can provide a preview of USD file export, and for developers it serves a reference. There are still limitations and missing features, especially around materials. The remaining to do items are tracked in #110765. This feature was contributed by AMD. Ref #110765 Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com> Co-authored-by: Vasyl-Pidhirskyi <vpidhirskyi@gmail.com> Co-authored-by: Brian Savery <brian.savery@gmail.com> Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/104712
2023-08-04 15:10:48 +02:00
# Hydra render engine
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_HYDRA "Enable Hydra render engine" ON)
Render: support USD Hydra render delegates Hydra is a rendering architecture part of USD, designed to abstract the host application from the renderer. A renderer implementing a Hydra render delegate can run in any host application supporting Hydra, which now includes Blender. For external renderers this means less code to be written, and improved performance due to a using a C++ API instead of a Python API. Add-ons need to subclass bpy.types.HydraRenderEngine. See the example in the Python API docs for details. An add-on for Hydra Storm will be included as well. This is USD's rasterizing renderer, used in other applications like usdview. For users it can provide a preview of USD file export, and for developers it serves a reference. There are still limitations and missing features, especially around materials. The remaining to do items are tracked in #110765. This feature was contributed by AMD. Ref #110765 Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com> Co-authored-by: Vasyl-Pidhirskyi <vpidhirskyi@gmail.com> Co-authored-by: Brian Savery <brian.savery@gmail.com> Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/104712
2023-08-04 15:10:48 +02:00
Core: Allow Optional Use of Harfbuzz and FriBiDi 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
2023-11-23 23:35:03 +01:00
# RTL Languages, Complex Shaping, OpenType Features
option(WITH_FRIBIDI "Enable features relying on fribidi" OFF)
option(WITH_HARFBUZZ "Enable features relying on harfbuzz" OFF)
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
# 3D format support
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_IO_WAVEFRONT_OBJ "Enable Wavefront-OBJ 3D file format support (*.obj)" ON)
option(WITH_IO_PLY "Enable PLY 3D file format support (*.ply)" ON)
option(WITH_IO_STL "Enable STL 3D file format support (*.stl)" ON)
IO: New FBX importer (C++, via ufbx) Adds a C++ based FBX importer, using 3rd party ufbx library (design task: #131304). The old Python based importer is still there; the new one is marked as "(experimental)" in the menu item. Drag-and-drop uses the old Python importer; the new one is only in the menu item. The new importer is generally 2x-5x faster than the old one, and often uses less memory too. There's potential to make it several times faster still. - ASCII FBX files are supported now - Binary FBX files older than 7.1 (SDK 2012) version are supported now - Better handling of "geometric transform" (common in 3dsmax), manifesting as wrong rotation for some objects when in a hierarchy (e.g. #131172) - Some FBX files that the old importer was failing to read are supported now (e.g. cases 47344, 134983) - Materials import more shader parameters (IOR, diffuse roughness, anisotropy, subsurface, transmission, coat, sheen, thin film) and shader models (e.g. OpenPBR or glTF2 materials from 3dsmax imports much better) - Importer now creates layered/slotted animation actions. Each "take" inside FBX file creates one action, and animated object within it gets a slot. - Materials that use the same texture several times no longer create duplicate images; the same image is used - Material diffuse color animations were imported, but they only animated the viewport color. Now they also animate the nodetree base color too. - "Ignore Leaf Bones" option no longer ignores leaf bones that are actually skinned to some parts of the mesh. - Previous importer was creating orphan invisible Camera data objects for some files (mostly from MotionBuilder?), new one properly creates these cameras. Import settings that existed in Python importer, but are NOT DONE in the new one (mostly because not sure if they are useful, and no one asked for them from feedback yet): - Manual Orientation & Forward/Up Axis: not sure if actually useful. FBX file itself specifies the axes fairly clearly. USD/glTF/Alembic also do not have settings to override them. - Use Pre/Post Rotation (defaults on): feels like it should just always be on. ufbx handles that internally. - Apply Transform (defaults off, warning icon): not sure if needed at all. - Decal Offset: Cycles specific. None of other importers have it. - Automatic Bone Orientation (defaults off): feels like current behavior (either on or off) often produces "nonsensical bones" where bone direction does not go towards the children with either setting. There are discussions within I/O and Animation modules about different ways of bone visualizations and/or different bone length axes, that would solve this in general. - Force Connect Children (defaults off): not sure when that would be useful. On several animated armatures I tried, it turns armature animation into garbage. - Primary/Secondary Bone Axis: again not sure when would be useful. Importer UI screenshots, performance benchmark details and TODOs for later work are in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/132406
2025-04-16 09:55:00 +02:00
option(WITH_IO_FBX "Enable FBX 3D file format support (*.fbx)" ON)
GPv3: Import and export for SVG and PDF Implements the SVG import/export and PDF export operators for GPv3. Pull Request: https://projects.blender.org/blender/blender/pulls/123996
2024-08-20 11:41:37 +02:00
option(WITH_IO_GREASE_PENCIL "Enable grease-pencil file format IO (*.svg, *.pdf)" ON)
- remove CPPFLAG XP_UNIX from CMake, Scons and Irix make, checked our own code and /usr/include, its only used in our netscape plugin. - CMake on unix default OpenMP to enabled. - Scons on linux default OpenMP to enabled. - copying python is slow, for scons only copy if the directory has not been created.
2009-11-19 11:49:42 +00:00
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
# Sound output
Core: remove sdlew/WITH_SDL_DYNLOAD & disable SDL by default Disable dynamic SDL loading as well as disable SDL for release builds. This was only used for audio output which can already use OpenAL if there are back-ends not natively supported by Blender. - Remove extern/sdlew/ - Remove the WITH_SDL_DYNLOAD build option. - Remove `bpy.app.sdl.available`. Ref !127554
2024-09-13 22:44:35 +10:00
option(WITH_SDL "Enable SDL for sound" OFF)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_OPENAL "Enable OpenAL Support (http://www.openal.org)" ON)
Audaspace: add support for CoreAudio on macOS This adds CoreAudio as audio backend on macOS. CoreAudio is the standard audio API on macOS. Ref T86590
2021-03-14 12:46:47 +01:00
if(APPLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_COREAUDIO "Enable CoreAudio for audio support on macOS" ON)
Audaspace: add support for CoreAudio on macOS This adds CoreAudio as audio backend on macOS. CoreAudio is the standard audio API on macOS. Ref T86590
2021-03-14 12:46:47 +01:00
else()
set(WITH_COREAUDIO OFF)
endif()
Build: add back WITH_JACK option on macOS, but disabled by default Jack has not been installed on the buildbot builders for a long time and so should not be enabled by default to pass strict build options added in D16104. However for those doing custom builds the option should remain available.
2022-11-14 19:14:49 +01:00
if(NOT WIN32)
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
set(_option_default ON)
Build: add back WITH_JACK option on macOS, but disabled by default Jack has not been installed on the buildbot builders for a long time and so should not be enabled by default to pass strict build options added in D16104. However for those doing custom builds the option should remain available.
2022-11-14 19:14:49 +01:00
if(APPLE)
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
set(_option_default OFF)
Build: add back WITH_JACK option on macOS, but disabled by default Jack has not been installed on the buildbot builders for a long time and so should not be enabled by default to pass strict build options added in D16104. However for those doing custom builds the option should remain available.
2022-11-14 19:14:49 +01:00
endif()
CMake: de-duplicate option(..) for platform specific defaults Use a variable for the default instead, avoid duplicate descriptions.
2023-01-25 11:53:50 +11:00
option(WITH_JACK "Enable JACK Support (http://www.jackaudio.org)" ${_option_default})
unset(_option_default)
option(WITH_JACK_DYNLOAD "Enable runtime dynamic JACK libraries loading" OFF)
Audaspace: porting minor improvements from upstream - NullDevice is now called None - Automatic choice of best available device. - Minor formatting, documentation and cmake fixes.
2021-03-16 22:32:16 +01:00
else()
set(WITH_JACK OFF)
Fix #33518: Jack sync doesn't work in 2.64, 2.64 or 2.65 stable versions Added new build option WITH_JACK_DYNLOAD for CMake and WITH_BF_JACK_DYNLOAD for SCons, which means there'll be no build-time linking against libjack and getting symbols from libjack will happen runtime using dlopen and dlsym tricks. Alternative would be to use weak linking, but it'll require having wrapper for preloading libjack. This new options are disabled by default and they only intended to be used on linux. Other platforms shall not be using this and there shall be no functional changes on non-linux platforms at all.
2013-03-27 07:19:54 +00:00
endif()
Audaspace: add support for PulseAudio on Linux This adds PulseAudio as audio backend on Linux. PulseAudio is the main audio engine used on most, if not all, Linux distributions today. Ref T86590
2021-03-02 17:29:18 +01:00
if(UNIX AND NOT APPLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_PULSEAUDIO "Enable PulseAudio for audio support on Linux" ON)
option(WITH_PULSEAUDIO_DYNLOAD "Enable runtime dynamic PulseAudio libraries loading" OFF)
Cmake: Add Pipewire support Pull Request: https://projects.blender.org/blender/blender/pulls/126091
2024-08-02 12:18:26 +02:00
option(WITH_PIPEWIRE "Enable Pipewire for audio support on Linux" ON)
option(WITH_PIPEWIRE_DYNLOAD "Enable runtime dynamic Pipewire libraries loading" OFF)
Audaspace: add support for PulseAudio on Linux This adds PulseAudio as audio backend on Linux. PulseAudio is the main audio engine used on most, if not all, Linux distributions today. Ref T86590
2021-03-02 17:29:18 +01:00
else()
set(WITH_PULSEAUDIO OFF)
Cmake: Add Pipewire support Pull Request: https://projects.blender.org/blender/blender/pulls/126091
2024-08-02 12:18:26 +02:00
set(WITH_PIPEWIRE OFF)
Audaspace: add support for PulseAudio on Linux This adds PulseAudio as audio backend on Linux. PulseAudio is the main audio engine used on most, if not all, Linux distributions today. Ref T86590
2021-03-02 17:29:18 +01:00
endif()
Audaspace: add support for WASAPI on Windows This adds WASAPI as audio backend on Windows. WASAPI is the modern standard audio API on Windows introduced with Windows Vista. Ref T86590
2021-03-11 19:22:56 +01:00
if(WIN32)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_WASAPI "Enable Windows Audio Sessions API for audio support on Windows" ON)
Audaspace: add support for WASAPI on Windows This adds WASAPI as audio backend on Windows. WASAPI is the modern standard audio API on Windows introduced with Windows Vista. Ref T86590
2021-03-11 19:22:56 +01:00
else()
set(WITH_WASAPI OFF)
endif()
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
# Compression
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_LZO "Enable fast LZO compression (used for pointcache)" ON)
option(WITH_LZMA "Enable best LZMA compression, (used for pointcache)" ON)
CMake: unbundle LZO library Patch T41989 by @hasufell
2015-03-13 22:33:31 +11:00
if(UNIX AND NOT APPLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_SYSTEM_LZO "Use the system LZO library" OFF)
CMake: unbundle LZO library Patch T41989 by @hasufell
2015-03-13 22:33:31 +11:00
endif()
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_DRACO "Enable Draco mesh compression Python module (used for glTF)" ON)
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
Camera tracking integration =========================== Commiting camera tracking integration gsoc project into trunk. This commit includes: - Bundled version of libmv library (with some changes against official repo, re-sync with libmv repo a bit later) - New datatype ID called MovieClip which is optimized to work with movie clips (both of movie files and image sequences) and doing camera/motion tracking operations. - New editor called Clip Editor which is currently used for motion/tracking stuff only, but which can be easily extended to work with masks too. This editor supports: * Loading movie files/image sequences * Build proxies with different size for loaded movie clip, also supports building undistorted proxies to increase speed of playback in undistorted mode. * Manual lens distortion mode calibration using grid and grease pencil * Supervised 2D tracking using two different algorithms KLT and SAD. * Basic algorithm for feature detection * Camera motion solving. scene orientation - New constraints to "link" scene objects with solved motions from clip: * Follow Track (make object follow 2D motion of track with given name or parent object to reconstructed 3D position of track) * Camera Solver to make camera moving in the same way as reconstructed camera This commit NOT includes changes from tomato branch: - New nodes (they'll be commited as separated patch) - Automatic image offset guessing for image input node and image editor (need to do more tests and gather more feedback) - Code cleanup in libmv-capi. It's not so critical cleanup, just increasing readability and understanadability of code. Better to make this chaneg when Keir will finish his current patch. More details about this project can be found on this page: http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011 Further development of small features would be done in trunk, bigger/experimental features would first be implemented in tomato branch.
2011-11-07 12:55:18 +00:00
# Camera/motion tracking
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_LIBMV "Enable Libmv structure from motion library" ON)
Build: change CMake option defaults to match "make full" Previously some important features like OpenSubdiv were disabled by default, which caused confusion. The purpose of disabling some of these features was to avoid potentiall build errors on Linux. But with precompiled libraries, install_deps.sh and better library availability checking this is hopefully not much of a problem anymore. This makes "make full" obsolete, but it's kept to not break docs or shell scripts that people may have, and the .cmake config file remains useful to modify an existing build folder. This also changes some option to only be available on platforms where they are actually supported (WITH_JACK, WITH_TBB_MALLOC_PROXY and X11 options). Fixes T69742 Differential Revision: https://developer.blender.org/D6306
2019-11-25 17:41:25 +01:00
option(WITH_LIBMV_SCHUR_SPECIALIZATIONS "Enable fixed-size schur specializations." ON)
CMake: disable some build option defaults T42569 This commit disables some lesser used dependencies for Linux/Unix systems by default. Run: `make full` to enabled options used in release build.
2014-11-13 23:32:01 +01:00
mark_as_advanced(WITH_LIBMV_SCHUR_SPECIALIZATIONS)
Camera tracking integration =========================== Commiting camera tracking integration gsoc project into trunk. This commit includes: - Bundled version of libmv library (with some changes against official repo, re-sync with libmv repo a bit later) - New datatype ID called MovieClip which is optimized to work with movie clips (both of movie files and image sequences) and doing camera/motion tracking operations. - New editor called Clip Editor which is currently used for motion/tracking stuff only, but which can be easily extended to work with masks too. This editor supports: * Loading movie files/image sequences * Build proxies with different size for loaded movie clip, also supports building undistorted proxies to increase speed of playback in undistorted mode. * Manual lens distortion mode calibration using grid and grease pencil * Supervised 2D tracking using two different algorithms KLT and SAD. * Basic algorithm for feature detection * Camera motion solving. scene orientation - New constraints to "link" scene objects with solved motions from clip: * Follow Track (make object follow 2D motion of track with given name or parent object to reconstructed 3D position of track) * Camera Solver to make camera moving in the same way as reconstructed camera This commit NOT includes changes from tomato branch: - New nodes (they'll be commited as separated patch) - Automatic image offset guessing for image input node and image editor (need to do more tests and gather more feedback) - Code cleanup in libmv-capi. It's not so critical cleanup, just increasing readability and understanadability of code. Better to make this chaneg when Keir will finish his current patch. More details about this project can be found on this page: http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011 Further development of small features would be done in trunk, bigger/experimental features would first be implemented in tomato branch.
2011-11-07 12:55:18 +00:00
CMake: Add option to link against system-wide Gflags library It is disabled by default, so should not affect existing configurations. Main benefits of this goes as: - Linux distros can use that to avoid libraries duplication and link blender package against gflags package from the system. - It it easier to test whether Blender works with updated version of Gflags prior to re-bundling the library.
2017-04-21 10:58:01 +02:00
# Logging/unbit test libraries.
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_SYSTEM_GFLAGS "Use system-wide Gflags instead of a bundled one" OFF)
option(WITH_SYSTEM_GLOG "Use system-wide Glog instead of a bundled one" OFF)
CMake: Add option to link against system-wide Gflags library It is disabled by default, so should not affect existing configurations. Main benefits of this goes as: - Linux distros can use that to avoid libraries duplication and link blender package against gflags package from the system. - It it easier to test whether Blender works with updated version of Gflags prior to re-bundling the library.
2017-04-21 10:58:01 +02:00
mark_as_advanced(WITH_SYSTEM_GFLAGS)
CMake: Add option to build against system-wide Glog Similar to previous commit for Gflags.
2017-04-21 14:26:25 +02:00
mark_as_advanced(WITH_SYSTEM_GLOG)
CMake: Add option to link against system-wide Gflags library It is disabled by default, so should not affect existing configurations. Main benefits of this goes as: - Linux distros can use that to avoid libraries duplication and link blender package against gflags package from the system. - It it easier to test whether Blender works with updated version of Gflags prior to re-bundling the library.
2017-04-21 10:58:01 +02:00
Another big patch set by Bastien Montagne, thanks a lot! * Made Freestyle optional (turned on by default). * Fix for missing bpath.c updates in the previous merge of trunk changes.
2012-12-20 07:57:26 +00:00
# Freestyle
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_FREESTYLE "Enable Freestyle (advanced edges rendering)" ON)
Another big patch set by Bastien Montagne, thanks a lot! * Made Freestyle optional (turned on by default). * Fix for missing bpath.c updates in the previous merge of trunk changes.
2012-12-20 07:57:26 +00:00
CMake: add WITH_LIBS_PRECOMPILED option (UNIX only) This makes it convenient to build blender without referencing pre-compiled libraries which don't always work on newer Linux systems. Previously I had to rename ../lib while creating the CMakeCache.txt to ensure my systems libraries would be used. This change ensures LIBDIR is undefined when WITH_LIBS_PRECOMPILED is disabled, so any accidental use warns with CMake's `--warn-unused-vars` argument is given.
2023-01-19 17:07:24 +11:00
# Libraries.
if(UNIX AND NOT APPLE)
# Optionally build without pre-compiled libraries.
# NOTE: this could be supported on all platforms however in practice UNIX is the only platform
# that has good support for detecting installed libraries.
option(WITH_LIBS_PRECOMPILED "\
Detect and link against pre-compiled libraries (typically found under \"../lib/\"). \
Disabling this option will use the system libraries although cached paths \
that point to pre-compiled libraries will be left as-is."
ON
)
mark_as_advanced(WITH_LIBS_PRECOMPILED)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_STATIC_LIBS "\
Try to link with static libraries, as much as possible, \
to make blender more portable across distributions"
OFF
)
CMake: add WITH_LIBS_PRECOMPILED option (UNIX only) This makes it convenient to build blender without referencing pre-compiled libraries which don't always work on newer Linux systems. Previously I had to rename ../lib while creating the CMakeCache.txt to ensure my systems libraries would be used. This change ensures LIBDIR is undefined when WITH_LIBS_PRECOMPILED is disabled, so any accidental use warns with CMake's `--warn-unused-vars` argument is given.
2023-01-19 17:07:24 +11:00
endif()
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
# Misc
GHOST/Wayland: IME support using the text-input protocol Tested with IBUS on GNOME 45. Added a capabilities flag to GHOST since support for IME works on Wayland but not on X11, so runtime detection is needed.
2023-10-19 09:09:59 +11:00
if(WIN32 OR APPLE OR ((UNIX AND (NOT HAIKU)) AND WITH_GHOST_WAYLAND))
Input Method Editor (IME) support for text buttons Original patch by @random (D765) with some minor work done by @campbell and me. At this place, I'd like call out a number of people who were involved and deserve a big "Thank you!": * At the first place @randon who developed and submitted the patch * The Blendercn community which helped a lot with testing - espacially * @yuzukyo, @leon_cheung and @kjym3 * @campbellbarton, @mont29 and @sergey for their help and advises during * review * @ton who realized the importance of this early on and asked me for * reviewing We are still not finished, as this is only the first part of the implementaion, but there's more to come!
2014-12-07 00:58:17 +01:00
option(WITH_INPUT_IME "Enable Input Method Editor (IME) for complex Asian character input" ON)
Cleanup: set WITH_INPUT_IME=OFF when unsupported This avoids having to do platform checks before checking WITH_INPUT_IME.
2023-10-18 22:04:25 +11:00
else()
set(WITH_INPUT_IME OFF)
Input Method Editor (IME) support for text buttons Original patch by @random (D765) with some minor work done by @campbell and me. At this place, I'd like call out a number of people who were involved and deserve a big "Thank you!": * At the first place @randon who developed and submitted the patch * The Blendercn community which helped a lot with testing - espacially * @yuzukyo, @leon_cheung and @kjym3 * @campbellbarton, @mont29 and @sergey for their help and advises during * review * @ton who realized the importance of this early on and asked me for * reviewing We are still not finished, as this is only the first part of the implementaion, but there's more to come!
2014-12-07 00:58:17 +01:00
endif()
Build: change CMake option defaults to match "make full" Previously some important features like OpenSubdiv were disabled by default, which caused confusion. The purpose of disabling some of these features was to avoid potentiall build errors on Linux. But with precompiled libraries, install_deps.sh and better library availability checking this is hopefully not much of a problem anymore. This makes "make full" obsolete, but it's kept to not break docs or shell scripts that people may have, and the .cmake config file remains useful to modify an existing build folder. This also changes some option to only be available on platforms where they are actually supported (WITH_JACK, WITH_TBB_MALLOC_PROXY and X11 options). Fixes T69742 Differential Revision: https://developer.blender.org/D6306
2019-11-25 17:41:25 +01:00
option(WITH_INPUT_NDOF "Enable NDOF input devices (SpaceNavigator and friends)" ON)
Fix "make bpy" on macOS not install libraries inside bpy module Default to WITH_PORTABLE_INSTALL behavior for this case, same as on Windows and Linux.
2023-11-01 18:28:53 +01:00
# On Windows and for the Blender application on macOS, portable install
# is the only supported installation type, so there is no option.
if(UNIX AND (NOT APPLE OR WITH_PYTHON_MODULE))
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_INSTALL_PORTABLE "\
Install redistributable runtime, otherwise install into CMAKE_INSTALL_PREFIX"
ON
)
CMake: Linux/Unix Only, use 'install' target rather then copying files with post-build commands. Main change is that you need to run 'make install', which copies files to ./bin by default unless WITH_INSTALL_PORTABLE is OFF, where CMAKE_INSTALL_PREFIX is used for a typical unix-system install.
2011-03-06 11:41:30 +00:00
endif()
CMake: only show py module install options when used
2016-03-15 23:50:44 +11:00
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
option(WITH_PYTHON_INSTALL "Copy system python into the blender install directory" ON)
Fix several issues with handling of numpy in CMake. 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
2020-12-14 16:40:00 +01:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_INSTALL_COPYRIGHT "\
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
Copy the official Blender Authors's copyright.txt into the Blender install directory"
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
OFF
)
Add option to install copyright.txt The file is specific for the builds created by the Blender Foundation and strictly speaking should only be used by builds created on our release environment. This change introduces a CMake option which is disabled by default and which will be enabled on our buildbot. Ref #107295 Pull Request: https://projects.blender.org/blender/blender/pulls/108191
2023-05-24 10:07:19 +02:00
mark_as_advanced(WITH_INSTALL_COPYRIGHT)
Fix several issues with handling of numpy in CMake. 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
2020-12-14 16:40:00 +01:00
if((WITH_AUDASPACE AND NOT WITH_SYSTEM_AUDASPACE) OR WITH_MOD_FLUID)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_PYTHON_NUMPY "Include NumPy in Blender (used by Audaspace and Mantaflow)" ON)
Fix several issues with handling of numpy in CMake. 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
2020-12-14 16:40:00 +01:00
endif()
CMake: remove PYTHON_NUMPY_INCLUDE_DIRS as a cache variable on macOS/Windows. It's in a fixed location on those platforms, and having it as a cache variable just means things break when we upgrade to a new Python version.
2018-09-17 11:10:45 +02:00
if(WIN32 OR APPLE)
# Windows and macOS have this bundled with Python libraries.
Fix several issues with handling of numpy in CMake. 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
2020-12-14 16:40:00 +01:00
elseif(WITH_PYTHON_INSTALL OR WITH_PYTHON_NUMPY)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(PYTHON_NUMPY_PATH "" CACHE PATH "\
Path to python site-packages or dist-packages containing 'numpy' module"
)
CMake: only show py module install options when used
2016-03-15 23:50:44 +11:00
mark_as_advanced(PYTHON_NUMPY_PATH)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(PYTHON_NUMPY_INCLUDE_DIRS "" CACHE PATH "Path to the include directory of the NumPy module")
Audaspace: Moving audaspace 1.3 into extern. Deleting the old internal audaspace. Major changes from there are: - The whole library was refactored to use C++11. - Many stability and performance improvements. - Major Python API refactor: - Most requested: Play self generated sounds using numpy arrays. - For games: Sound list, random sounds and dynamic music. - Writing sounds to files. - Sequencing API. - Opening sound devices, eg. Jack. - Ability to choose different OpenAL devices in the user settings.
2017-08-18 08:24:12 +02:00
mark_as_advanced(PYTHON_NUMPY_INCLUDE_DIRS)
endif()
if(WITH_PYTHON_INSTALL)
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
option(WITH_PYTHON_INSTALL_NUMPY "Copy system NumPy into the blender install directory" ON)
CMake: only show py module install options when used
2016-03-15 23:50:44 +11:00
if(UNIX AND NOT APPLE)
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
option(WITH_PYTHON_INSTALL_REQUESTS "\
Copy system requests into the blender install directory"
ON
)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(PYTHON_REQUESTS_PATH "" CACHE PATH "\
Path to python site-packages or dist-packages containing 'requests' module"
)
CMake: only show py module install options when used
2016-03-15 23:50:44 +11:00
mark_as_advanced(PYTHON_REQUESTS_PATH)
endif()
Deps: Python, bundle zstandard package This package allows Python scripts to handle compressed blend files (see rB2ea66af742bc). This is for example needed by Blender Asset Tracer to send files to a Flamenco render farm. This change includes a new `WITH_PYTHON_INSTALL_ZSTANDARD` build-time option, to control whether to actually install the package. For this the already-existing approach for Requests was copied. Reviewed By: LazyDodo, mont29, brecht Differential Revision: https://developer.blender.org/D12777
2021-10-21 13:45:37 +02:00
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
option(WITH_PYTHON_INSTALL_ZSTANDARD "Copy zstandard into the blender install directory" ON)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(PYTHON_ZSTANDARD_PATH "" CACHE PATH "\
Path to python site-packages or dist-packages containing 'zstandard' module"
)
Deps: Python, bundle zstandard package This package allows Python scripts to handle compressed blend files (see rB2ea66af742bc). This is for example needed by Blender Asset Tracer to send files to a Flamenco render farm. This change includes a new `WITH_PYTHON_INSTALL_ZSTANDARD` build-time option, to control whether to actually install the package. For this the already-existing approach for Requests was copied. Reviewed By: LazyDodo, mont29, brecht Differential Revision: https://developer.blender.org/D12777
2021-10-21 13:45:37 +02:00
mark_as_advanced(PYTHON_ZSTANDARD_PATH)
CMake: only show py module install options when used
2016-03-15 23:50:44 +11:00
endif()
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CPU_SIMD "Enable SIMD instruction if they're detected on the host machine" ON)
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
mark_as_advanced(WITH_CPU_SIMD)
cmake - improved detection of numpy, now works for typical ubuntu installation. numpy directory can be referenced manually with the advanced option PYTHON_NUMPY_PATH if needed.
2012-05-01 23:22:58 +00:00
Cycles: hook up the CMake build system. New build instructions for Ubuntu Linux in the wiki: http://wiki.blender.org/index.php/Dev:2.5/Source/Cycles
2011-04-28 13:47:27 +00:00
# Cycles
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES "Enable Cycles Render Engine" ON)
option(WITH_CYCLES_OSL "Build Cycles with OpenShadingLanguage support" ON)
option(WITH_CYCLES_PATH_GUIDING "Build Cycles with path guiding support" ON)
option(WITH_CYCLES_EMBREE "Build Cycles with Embree support" ON)
option(WITH_CYCLES_DEBUG "Build Cycles with options useful for debugging (e.g., MIS)" OFF)
Build: improve descriptions and organization of Cycles build options
2021-10-22 08:31:47 +02:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_STANDALONE "Build Cycles standalone application" OFF)
option(WITH_CYCLES_STANDALONE_GUI "Build Cycles standalone with GUI" OFF)
option(WITH_CYCLES_PRECOMPUTE "Build Cycles data precomputation tool" OFF)
Build: improve descriptions and organization of Cycles build options
2021-10-22 08:31:47 +02:00
Cycles: Add Hydra render delegate This patch adds a Hydra render delegate to Cycles, allowing Cycles to be used for rendering in applications that provide a Hydra viewport. The implementation was written from scratch against Cycles X, for integration into the Blender repository to make it possible to continue developing it in step with the rest of Cycles. For this purpose it follows the style of the rest of the Cycles code and can be built with a CMake option (`WITH_CYCLES_HYDRA_RENDER_DELEGATE=1`) similar to the existing standalone version of Cycles. Since Hydra render delegates need to be built against the exact USD version and other dependencies as the target application is using, this is intended to be built separate from Blender (`WITH_BLENDER=0` CMake option) and with support for library versions different from what Blender is using. As such the CMake build scripts for Windows had to be modified slightly, so that the Cycles Hydra render delegate can e.g. be built with MSVC 2017 again even though Blender requires MSVC 2019 now, and it's possible to specify custom paths to the USD SDK etc. The codebase supports building against the latest USD release 22.03 and all the way back to USD 20.08 (with some limitations). Reviewed By: brecht, LazyDodo Differential Revision: https://developer.blender.org/D14398
2022-03-23 16:07:43 +01:00
option(WITH_CYCLES_HYDRA_RENDER_DELEGATE "Build Cycles Hydra render delegate" OFF)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_DEBUG_NAN "\
Build Cycles with additional asserts for detecting NaNs and invalid values"
OFF
)
option(WITH_CYCLES_NATIVE_ONLY "\
Build Cycles with native kernel only (which fits current CPU, use for development only)"
OFF
)
option(WITH_CYCLES_KERNEL_ASAN "\
Build Cycles kernels with address sanitizer when WITH_COMPILER_ASAN is on, even if it's very slow"
OFF
)
set(CYCLES_TEST_DEVICES CPU CACHE STRING "\
Cleanup: wrap long lines for CMake
2025-04-05 20:21:57 +11:00
Run regression tests on the specified device types \
(CPU CUDA OPTIX HIP HIP-RT METAL METAL-RT ONEAPI ONEAPI-RT)"
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
)
Cycles render tests: Add the option to test with OSL enabled This commit adds a new cmake variable `WITH_CYCLES_TEST_OSL` that runs every Cycles test a second time with OSL enabled. At the moment only CPU OSL is enabled. There are plans to enable OptiX OSL in the future when stability issues with OptiX OSL have been resolved. Some render tests have been blocked from running until we can figure out a fix. The most notiable being all the Pricincipled BSDF tests as some of them are failing due to noise differences. Ref #123012 Pull Request: https://projects.blender.org/blender/blender/pulls/124601
2024-08-14 17:00:48 +02:00
option(WITH_CYCLES_TEST_OSL "\
Run additional Cycles test with OSL enabled"
OFF
)
Build: disable address sanitizer for Cycles optimized kernels with GCC It's extremely slow to compile and run, so just disable it unless WITH_CYCLES_KERNEL_ASAN is manually enabled. For Clang it's always enabled since that appears to work ok. This also limits the -fno-sanitize=vptr flag to the Cycles kernel, as it was added specifically to work around an issue there. Differential Revision: https://developer.blender.org/D5404
2019-07-11 19:29:29 +02:00
mark_as_advanced(WITH_CYCLES_KERNEL_ASAN)
Cycles: remove WITH_CYCLES_DEBUG, add WITH_CYCLES_DEBUG_NAN WITH_CYCLES_DEBUG was used for rendering BVH debugging passes. But since we mainly use Embree an OptiX now, this information is no longer important. WITH_CYCLES_DEBUG_NAN will enable additional checks for NaNs and invalid values in the kernel, for Cycles developers. Previously these asserts where enabled in all debug builds, but this is too likely to crash Blender in scenes that render fine regardless of the NaNs. So this is behind a CMake option now. Fixes T90240
2021-07-28 18:27:25 +02:00
mark_as_advanced(WITH_CYCLES_DEBUG_NAN)
Cycles: Add an option to build single kernel only which fits current CPU This seems quite useful for the development, so you don't need to wait all the kernels to be re-compiled when working on a new feature, which speeds up re-iteration. Marked as an advanced option, so if it doesn't work so well in practice it's safe to revert anyway.
2016-03-25 16:09:05 +01:00
mark_as_advanced(WITH_CYCLES_NATIVE_ONLY)
Cycles: Remove MultiGGX code, replace with albedo scaling While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time. In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses. This can simply be achieved by adding a second lobe (https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf) or scaling the single-scattering GGX lobe (https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf). Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient. Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases). In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models). Pull Request: https://projects.blender.org/blender/blender/pulls/107958
2023-06-05 02:20:57 +02:00
mark_as_advanced(WITH_CYCLES_PRECOMPUTE)
CMake: use mark_as_advancd for most non WITH_* options Avoid showing many obscure CMake options by default.
2023-07-10 12:02:15 +10:00
mark_as_advanced(CYCLES_TEST_DEVICES)
Cycles render tests: Add the option to test with OSL enabled This commit adds a new cmake variable `WITH_CYCLES_TEST_OSL` that runs every Cycles test a second time with OSL enabled. At the moment only CPU OSL is enabled. There are plans to enable OptiX OSL in the future when stability issues with OptiX OSL have been resolved. Some render tests have been blocked from running until we can figure out a fix. The most notiable being all the Pricincipled BSDF tests as some of them are failing due to noise differences. Ref #123012 Pull Request: https://projects.blender.org/blender/blender/pulls/124601
2024-08-14 17:00:48 +02:00
mark_as_advanced(WITH_CYCLES_TEST_OSL)
Cycles: hook up the CMake build system. New build instructions for Ubuntu Linux in the wiki: http://wiki.blender.org/index.php/Dev:2.5/Source/Cycles
2011-04-28 13:47:27 +00:00
Build: improve descriptions and organization of Cycles build options
2021-10-22 08:31:47 +02:00
# NVIDIA CUDA & OptiX
Cleanup: use STREQUAL instead of MATCHES for exact comparisons MATCHES takes a REGEX and searches the input for a match, this isn't necessary for CMAKE_SYSTEM_PROCESSOR & CMAKE_*_COMPILER_ID.
2024-03-07 17:56:41 +11:00
if(NOT APPLE AND NOT (WIN32 AND CMAKE_SYSTEM_PROCESSOR STREQUAL "ARM64"))
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_DEVICE_CUDA "Enable Cycles NVIDIA CUDA compute support" ON)
option(WITH_CYCLES_DEVICE_OPTIX "Enable Cycles NVIDIA OptiX support" ON)
Build: remove Cycles CUDA/HIP/OPTIX build options on macOS So those device types are not listed in the preferences. Metal will be added instead as the only option.
2021-12-07 18:27:51 +01:00
mark_as_advanced(WITH_CYCLES_DEVICE_CUDA)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_CUDA_BINARIES "Build Cycles NVIDIA CUDA binaries" OFF)
set(CYCLES_CUDA_BINARIES_ARCH
Cycles: Bump minimum supported CUDA architecture to sm_50 Pull Request: https://projects.blender.org/blender/blender/pulls/142212
2025-07-21 19:49:21 +02:00
sm_50 sm_52 sm_60 sm_61 sm_70 sm_75 sm_86 sm_89 sm_120 compute_75
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
CACHE STRING "CUDA architectures to build binaries for"
)
option(WITH_CYCLES_CUDA_BUILD_SERIAL "\
Build cubins one after another (useful on machines with limited RAM)"
OFF
)
option(WITH_CUDA_DYNLOAD "\
Dynamically load CUDA libraries at runtime (for developers, makes cuda-gdb work)"
ON
)
Cycles: add option to specify OptiX runtime root directory This allows individual users or Linux distributions to specify a directory Cycles will automatically look for the OptiX include folder, to compile kernels at runtime. It is still possible to override this with the OPTIX_ROOT_DIR environment variable at runtime. Based on patch by Sebastian Parborg. Ref D15792
2022-08-29 19:12:15 +02:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(OPTIX_ROOT_DIR "" CACHE PATH "\
Path to the OptiX SDK root directory, for building Cycles OptiX kernels."
)
set(CYCLES_RUNTIME_OPTIX_ROOT_DIR "" CACHE PATH "\
Path to the OptiX SDK root directory. \
When set, this path will be used at runtime to compile OptiX kernels."
)
Cycles: add option to specify OptiX runtime root directory This allows individual users or Linux distributions to specify a directory Cycles will automatically look for the OptiX include folder, to compile kernels at runtime. It is still possible to override this with the OPTIX_ROOT_DIR environment variable at runtime. Based on patch by Sebastian Parborg. Ref D15792
2022-08-29 19:12:15 +02:00
Build: remove Cycles CUDA/HIP/OPTIX build options on macOS So those device types are not listed in the preferences. Metal will be added instead as the only option.
2021-12-07 18:27:51 +01:00
mark_as_advanced(CYCLES_CUDA_BINARIES_ARCH)
mark_as_advanced(WITH_CYCLES_CUDA_BUILD_SERIAL)
mark_as_advanced(WITH_CUDA_DYNLOAD)
Cycles: add option to specify OptiX runtime root directory This allows individual users or Linux distributions to specify a directory Cycles will automatically look for the OptiX include folder, to compile kernels at runtime. It is still possible to override this with the OPTIX_ROOT_DIR environment variable at runtime. Based on patch by Sebastian Parborg. Ref D15792
2022-08-29 19:12:15 +02:00
mark_as_advanced(OPTIX_ROOT_DIR)
mark_as_advanced(CYCLES_RUNTIME_OPTIX_ROOT_DIR)
Build: remove Cycles CUDA/HIP/OPTIX build options on macOS So those device types are not listed in the preferences. Metal will be added instead as the only option.
2021-12-07 18:27:51 +01:00
endif()
Cycles: Add option to directly link against CUDA libraries The main purpose of such linking is to make Blender compatible with NVidia's debuggers and profilers which are doing some LD_PRELOAD magic to intercept some function calls. Such magic conflicts with our CUDA wrangler magic and causes segmentation faults. The option is disabled by default, so there's no affect on any of artists. In order to make Blender linked directly against CUDA library use the WITH_CUDA_DYNLOAD CMake option (it's marked as advanced).
2016-01-14 12:24:09 +05:00
Build: improve descriptions and organization of Cycles build options
2021-10-22 08:31:47 +02:00
# AMD HIP
Cleanup: use STREQUAL instead of MATCHES for exact comparisons MATCHES takes a REGEX and searches the input for a match, this isn't necessary for CMAKE_SYSTEM_PROCESSOR & CMAKE_*_COMPILER_ID.
2024-03-07 17:56:41 +11:00
if(NOT APPLE AND NOT (WIN32 AND CMAKE_SYSTEM_PROCESSOR STREQUAL "ARM64"))
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_DEVICE_HIP "Enable Cycles AMD HIP support" ON)
option(WITH_CYCLES_HIP_BINARIES "Build Cycles AMD HIP binaries" OFF)
Cleanup: wrap long lines for CMake
2025-04-05 20:21:57 +11:00
# We only support RDNA1 (gfx101X) and newer.
# Vega and older generations have rendering artifacts and crashing issues.
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(CYCLES_HIP_BINARIES_ARCH
Cycles: enable HIP for integrated graphics of Ryzen 7000 CPUs Specifically the gfx1036 architecture, for AMD Zen4 APUs. Pull Request: https://projects.blender.org/blender/blender/pulls/110907
2023-08-16 14:35:09 +02:00
gfx1010 gfx1011 gfx1012
gfx1030 gfx1031 gfx1032 gfx1034 gfx1035 gfx1036
Cycles: HIP-RT 2.5 integration and gfx12 support This change brings the following improvements on the user level - Support of GPUs with gfx12 architecture - New HIP-RT library which in addition to the gfx12 support brings various bug-fixes. The known limitation of gfx12 is that OpenImageDenoiser does not yet support this GPU architecture. This means that while Cycles will use the full advantage of the gfx12 (including hardware accelerated ray-tracing), denoising will only be possible on CPU, or secondary gfx11 or below GPU. This is something that requires a change in OIDN and it is to late to do it for Blender 4.4, but it is something to look forward for Blender 4.5. The gfx12 changes for the pre-compiled kernels is rather trivial, so it comes together (in the same PR) as the bigger HIP-RT change. On the development side this change brings the following improvements: - One step compile and link (much simpler CMake rules) - Embedding BVH binaries in hiprt dll (which makes it easier to package and load, without relying on special path configuration) Co-authored-by: Sahar Kashi <sahar.kashi@amd.com> Co-authored-by: Sergey Sharybin <sergey@blender.org> Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/133129
2025-02-20 17:34:14 +01:00
gfx1100 gfx1101 gfx1102 gfx1103 gfx1150 gfx1151 gfx1152
gfx1200 gfx1201
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
CACHE STRING "AMD HIP architectures to build binaries for"
)
Build: remove Cycles CUDA/HIP/OPTIX build options on macOS So those device types are not listed in the preferences. Metal will be added instead as the only option.
2021-12-07 18:27:51 +01:00
mark_as_advanced(WITH_CYCLES_DEVICE_HIP)
mark_as_advanced(CYCLES_HIP_BINARIES_ARCH)
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 19:05:30 +02:00
Cycles: Linux Support for HIP-RT This change switches Cycles to an opensource HIP-RT library which implements hardware ray-tracing. This library is now used on both Windows and Linux. While there should be no noticeable changes on Windows, on Linux this adds support for hardware ray-tracing on AMD GPUs. The majority of the change is typical platform code to add new library to the dependency builder, and a change in the way how ahead-of-time (AoT) kernels are compiled. There are changes in Cycles itself, but they are rather straightforward: some APIs changed in the opensource version of the library. There are a couple of extra files which are needed for this to work: hiprt02003_6.1_amd.hipfb and oro_compiled_kernels.hipfb. There are some assumptions in the HIP-RT library about how they are available. Currently they follow the same rule as AoT kernels for oneAPI: - On Windows they are next to blender.exe - On Linux they are in the lib/ folder Performance comparison on Ubuntu 22.04.5: ``` GPU: AMD Radeon PRO W7800 Driver: amdgpu-install_6.1.60103-1_all.deb main hip-rt attic 0.1414s 0.0932s barbershop_interior 0.1563s 0.1258s bistro 0.2134s 0.1597s bmw27 0.0119s 0.0099s classroom 0.1006s 0.0803s fishy_cat 0.0248s 0.0178s junkshop 0.0916s 0.0713s koro 0.0589s 0.0720s monster 0.0435s 0.0385s pabellon 0.0543s 0.0391s sponza 0.0223s 0.0180s spring 0.1026s 1.5145s victor 0.1901s 0.1239s wdas_cloud 0.1153s 0.1125s ``` Co-authored-by: Brecht Van Lommel <brecht@blender.org> Co-authored-by: Ray Molenkamp <github@lazydodo.com> Co-authored-by: Sergey Sharybin <sergey@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/121050
2024-09-24 14:35:24 +02:00
option(WITH_CYCLES_DEVICE_HIPRT "Enable Cycles AMD HIPRT support" OFF)
mark_as_advanced(WITH_CYCLES_DEVICE_HIPRT)
Cycles: enable HIP device and binaries on Windows We've now done testing to confirm this works with RDNA and RDNA2 AMD GPUs on Windows. The AMD driver needed for this will soon be released publicly.
2021-11-09 16:00:06 +01:00
endif()
Build: improve descriptions and organization of Cycles build options
2021-10-22 08:31:47 +02:00
Cycles: enable Metal GPU rendering This adds the remaining bits to enable Metal on macOS. There are still performance optimizations and other improvements planned, but it should now be ready for early testing. This is currently only enabled on in Arm builds for M1 GPUs. It is not yet working on AMD or Intel GPUs. Ref T92212 Differential Revision: https://developer.blender.org/D13503
2021-12-13 13:48:36 +01:00
# Apple Metal
if(APPLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_DEVICE_METAL "Enable Cycles Apple Metal compute support" ON)
Cycles: enable Metal GPU rendering This adds the remaining bits to enable Metal on macOS. There are still performance optimizations and other improvements planned, but it should now be ready for early testing. This is currently only enabled on in Arm builds for M1 GPUs. It is not yet working on AMD or Intel GPUs. Ref T92212 Differential Revision: https://developer.blender.org/D13503
2021-12-13 13:48:36 +01:00
endif()
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
# oneAPI
Cleanup: use STREQUAL instead of MATCHES for exact comparisons MATCHES takes a REGEX and searches the input for a match, this isn't necessary for CMAKE_SYSTEM_PROCESSOR & CMAKE_*_COMPILER_ID.
2024-03-07 17:56:41 +11:00
if(NOT APPLE AND NOT (WIN32 AND CMAKE_SYSTEM_PROCESSOR STREQUAL "ARM64"))
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
option(WITH_CYCLES_DEVICE_ONEAPI "Enable Cycles oneAPI compute support" OFF)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CYCLES_ONEAPI_BINARIES "\
Enable Ahead-Of-Time compilation for Cycles oneAPI device"
OFF
)
option(WITH_CYCLES_ONEAPI_HOST_TASK_EXECUTION "\
Switch target of oneAPI implementation from SYCL devices to Host Task (single thread on CPU). \
This option is only for debugging purposes."
OFF
)
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
# https://www.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top/compilation/ahead-of-time-compilation.html
Cycles: oneAPI: use ocloc 101.5972 on Windows This new version of the graphics compiler solves a performance regression on Arc, adds support for Battlemage and Lunar Lake GPUs, and allows to drop older patch to build fat binaries with broad compatibility. This latter change requires using -device dg2,mtl naming instead of passing architecture ids. Pull Request: https://projects.blender.org/blender/blender/pulls/127371
2024-09-09 21:34:33 +02:00
# The supported devices can be retrieved from `ocloc` output when running
# `ocloc compile --help`.
Cycles: Show device optimizations status in preferences for oneAPI With these changes, we can now mark devices which are expected to work as performant as possible, and devices which were not optimized for some reason. For example, because the device was released after the Blender release, making it impossible for developers to optimize for devices in already released unchangeable code. This is primarily relevant for the LTS versions, which are supported for two years and require proper communication about optimization status for the new devices released during this time. This is implemented for oneAPI devices. Other device types currently are marked as optimized for compatibility with old behavior, but may implement the same in the future. Pull Request: https://projects.blender.org/blender/blender/pulls/139751
2025-06-03 20:07:52 +02:00
# If you have completed optimization work and now want to enable AoT for new Intel devices,
# update the optimization status in OneapiDevice::architecture_information.
Cycles: oneAPI: build binaries for Battlemage GPUs
2024-11-13 00:04:03 +01:00
set(CYCLES_ONEAPI_INTEL_BINARIES_ARCH dg2 mtl lnl bmg CACHE STRING "\
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
oneAPI Intel GPU architectures to build binaries for"
)
set(CYCLES_ONEAPI_SYCL_TARGETS spir64 spir64_gen CACHE STRING "\
oneAPI targets to build AOT binaries for"
)
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
Cycles: oneAPI: add support for SYCL host task This functionality is related only to debugging of SYCL implementation via single-threaded CPU execution and is disabled by default. Host device has been deprecated in SYCL 2020 spec and we removed it in 305b92e05f748a0fd9cb62b9829791d717ba2d57. Since this is still very useful for debugging, we're restoring a similar functionality here through SYCL 2020 Host Task.
2023-01-03 20:45:57 +01:00
mark_as_advanced(WITH_CYCLES_ONEAPI_HOST_TASK_EXECUTION)
Cycles: oneAPI: rename target intel arch cmake setting CYCLES_ONEAPI_SPIR64_GEN_DEVICES -> CYCLES_ONEAPI_INTEL_BINARIES_ARCH so it's more aligned with the name for the other backends, such as CYCLES_CUDA_BINARIES_ARCH.
2023-09-21 13:33:06 +02:00
mark_as_advanced(CYCLES_ONEAPI_INTEL_BINARIES_ARCH)
Cycles: Add support for rendering on Intel GPUs using oneAPI This patch adds a new Cycles device with similar functionality to the existing GPU devices. Kernel compilation and runtime interaction happen via oneAPI DPC++ compiler and SYCL API. This implementation is primarly focusing on Intel® Arc™ GPUs and other future Intel GPUs. The first supported drivers are 101.1660 on Windows and 22.10.22597 on Linux. The necessary tools for compilation are: - A SYCL compiler such as oneAPI DPC++ compiler or https://github.com/intel/llvm - Intel® oneAPI Level Zero which is used for low level device queries: https://github.com/oneapi-src/level-zero - To optionally generate prebuilt graphics binaries: Intel® Graphics Compiler All are included in Linux precompiled libraries on svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for Windows precompiled binaries but for the graphics compiler, available as "Intel® Graphics Offline Compiler for OpenCL™ Code" from https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html, for which path can be set as OCLOC_INSTALL_DIR. Being based on the open SYCL standard, this implementation could also be extended to run on other compatible non-Intel hardware in the future. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D15254 Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com> Co-authored-by: Stefan Werner <stefan.werner@intel.com>
2022-06-29 12:58:04 +02:00
mark_as_advanced(CYCLES_ONEAPI_SYCL_TARGETS)
endif()
DRW: New Select Debug Engine This is a simple engine used only to debug the texture of select ids. It is only used when the `WITH_DRAW_DEBUG` option is enabled and the debug value is 31. Reviewed By: fclem Differential Revision: https://developer.blender.org/D5490
2021-08-03 13:39:30 -03:00
# Draw Manager
option(WITH_DRAW_DEBUG "Add extra debug capabilities to Draw Manager" OFF)
mark_as_advanced(WITH_DRAW_DEBUG)
Better support for LLVM linking, needed for static OSL library. This adds cmake code for LLVM on linux and updates the cmake code used for OSX. LLVM is linked like other external libraries now, by using the setup_liblinks and setup_libdirs macros instead of the PLATFORM_LINKFLAGS variable. The use of llvm-config for getting a list of libraries can also be simplified quite a bit. Caching the LLVM_DIRECTORY and LLVM_VERSION strings could be nicer though.
2012-10-06 11:00:45 +00:00
# LLVM
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_LLVM "Use LLVM" OFF)
Build: Remove LLVM linking no longer needed by OSL These are now included in the OSL shared libraries, so no reason to link against it. The CMake code for WITH_LLVM remains in case it is useful in the future, but is not enabled by any Blender feature now. Pull Request: https://projects.blender.org/blender/blender/pulls/118229
2024-02-14 12:06:52 +01:00
option(LLVM_STATIC "Link with LLVM static libraries" OFF)
CMake: add LLVM_STATIC as cmake build option, so linux distributions can link LLVM dynamically. Patch by Dan Eicher.
2013-04-15 16:18:35 +00:00
mark_as_advanced(LLVM_STATIC)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CLANG "Use Clang" OFF)
Better support for LLVM linking, needed for static OSL library. This adds cmake code for LLVM on linux and updates the cmake code used for OSX. LLVM is linked like other external libraries now, by using the setup_liblinks and setup_libdirs macros instead of the PLATFORM_LINKFLAGS variable. The use of llvm-config for getting a list of libraries can also be simplified quite a bit. Caching the LLVM_DIRECTORY and LLVM_VERSION strings could be nicer though.
2012-10-06 11:00:45 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_MEM_JEMALLOC "Enable malloc replacement (http://www.canonware.com/jemalloc)" ON)
option to link with jemalloc on *nix, off by default.
2011-05-12 11:16:32 +00:00
mark_as_advanced(WITH_MEM_JEMALLOC)
add cmake option WITH_MEM_VALGRIND, helps to track down errors with mempool use which sometimes only show up as bugs in very rare cases (because even though the element is freed, the chunk is still allocated).
2013-10-03 12:22:44 +00:00
# currently only used for BLI_mempool
option(WITH_MEM_VALGRIND "Enable extended valgrind support for better reporting" OFF)
mark_as_advanced(WITH_MEM_VALGRIND)
CMake: enable WITH_ASSERT_ABORT by default Assert from BLI_assert by default in debug builds (instead of just printing a warning). Some developers ignored this, causing errors for others. Better debug builds cause hard error so code isn't ignored. Disabling is still useful when bisecting or testing outdated code.
2018-06-28 10:48:06 +02:00
option(WITH_ASSERT_ABORT "Call abort() when raising an assertion through BLI_assert()" ON)
BKE_assert(), only prints the error unless cmake define WITH_ASSERT_ABORT is enabled and it will call abort(). made this option advanced so people don't enable along with other features.
2010-12-15 10:22:26 +00:00
mark_as_advanced(WITH_ASSERT_ABORT)
CMake: Allow asserts to be enabled for release builds. 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
2023-12-06 23:49:42 +01:00
option(WITH_ASSERT_RELEASE "Build with asserts enabled even for non-debug configurations" OFF)
mark_as_advanced(WITH_ASSERT_RELEASE)
macOS: Add support for clang-tidy checks during compilation This commit adds support for clang-tidy checks during compilation on macOS, which can now be enabled using the optional `WITH_CLANG_TIDY` CMake variable. The clang-tidy executable doesn't need to be separately installed since CMake will pick up the executable from the LLVM pre-compiled library. This commit also expands the coverage of clang-tidy checks to Objective-C/C++, for which checks were enabled in PR #128334. Pull Request: https://projects.blender.org/blender/blender/pulls/129761
2024-11-13 16:14:01 +01:00
if(UNIX OR (CMAKE_GENERATOR MATCHES "^Visual Studio.+"))
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_CLANG_TIDY "\
Use Clang Tidy to analyze the source code \
(only enable for development on Linux using Clang, or Windows using the Visual Studio IDE)"
OFF
)
Initial support of clang-tidy toolchain 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
2020-06-05 11:37:49 +02:00
mark_as_advanced(WITH_CLANG_TIDY)
endif()
Build: add WITH_TBB option, in preparation of sculpt using it It should no longer be tied to OpenVDB and OpenImageDenoise then. Differential Revision: https://developer.blender.org/D6029
2019-10-09 16:44:29 +02:00
option(WITH_BOOST "Enable features depending on boost" ON)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_TBB "\
Enable multi-threading. TBB is also required for features such as Cycles, OpenVDB and USD"
ON
)
Build: change CMake option defaults to match "make full" Previously some important features like OpenSubdiv were disabled by default, which caused confusion. The purpose of disabling some of these features was to avoid potentiall build errors on Linux. But with precompiled libraries, install_deps.sh and better library availability checking this is hopefully not much of a problem anymore. This makes "make full" obsolete, but it's kept to not break docs or shell scripts that people may have, and the .cmake config file remains useful to modify an existing build folder. This also changes some option to only be available on platforms where they are actually supported (WITH_JACK, WITH_TBB_MALLOC_PROXY and X11 options). Fixes T69742 Differential Revision: https://developer.blender.org/D6306
2019-11-25 17:41:25 +01:00
# TBB malloc is only supported on for windows currently
Windows: Disable TBB_MALLOC_PROXY on ARM64 Currently, every time blender starts on one of these platforms, we get the following warning (doesn't affect how it runs, all tests pass anyway): ``` TBBmalloc: skip allocation functions replacement in ucrtbase.dll: unknown prologue for function free ``` This is due to TBB_MALLOC_PROXY not working on these platforms (happens with emulated x64 too). I suspect it is fixed in the newer oneTBB releases that have proper support for Windows on Arm, rather than the patch I made to enable 2020u3. This can be revisited once the TBB version is updated. Pull Request: https://projects.blender.org/blender/blender/pulls/124148
2024-07-04 17:14:42 +02:00
if(WIN32 AND NOT CMAKE_SYSTEM_PROCESSOR STREQUAL "ARM64")
Build: change CMake option defaults to match "make full" Previously some important features like OpenSubdiv were disabled by default, which caused confusion. The purpose of disabling some of these features was to avoid potentiall build errors on Linux. But with precompiled libraries, install_deps.sh and better library availability checking this is hopefully not much of a problem anymore. This makes "make full" obsolete, but it's kept to not break docs or shell scripts that people may have, and the .cmake config file remains useful to modify an existing build folder. This also changes some option to only be available on platforms where they are actually supported (WITH_JACK, WITH_TBB_MALLOC_PROXY and X11 options). Fixes T69742 Differential Revision: https://developer.blender.org/D6306
2019-11-25 17:41:25 +01:00
option(WITH_TBB_MALLOC_PROXY "Enable the TBB malloc replacement" ON)
endif()
expose WITH_BOOST as a cmake option, this just disables boost deps since it was becoming annoying to remember all of them.
2013-01-31 23:25:06 +00:00
CMake: Add build option to disable experimental features This adds an option `WITH_EXPERIMENTAL_FEATURES` which is `ON` by default. Sometimes it's usefull to be able to turn off all experimental features during development for testing purposes. This option is still enforced to be `OFF` for release cycles other than `alpha`. Pull Request: https://projects.blender.org/blender/blender/pulls/118513
2024-02-21 09:57:40 +01:00
option(WITH_EXPERIMENTAL_FEATURES "Enable experimental features" ON)
Remove (ifdef) RNA for simulation, point cloud and particles 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
2020-08-17 09:47:10 +02:00
# This should be turned off when Blender enter beta/rc/release
CMake: Add build option to disable experimental features This adds an option `WITH_EXPERIMENTAL_FEATURES` which is `ON` by default. Sometimes it's usefull to be able to turn off all experimental features during development for testing purposes. This option is still enforced to be `OFF` for release cycles other than `alpha`. Pull Request: https://projects.blender.org/blender/blender/pulls/118513
2024-02-21 09:57:40 +01:00
if("${BLENDER_VERSION_CYCLE}" STREQUAL "alpha" AND WITH_EXPERIMENTAL_FEATURES)
CMake: Force experimental features to be on/off based on release cycle 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.
2020-09-09 16:07:29 +02:00
set(WITH_EXPERIMENTAL_FEATURES ON)
CMake mini-rewrite: Sync code check with BKE_blender_version_is_alpha Reproduce the logic we already do in C (BKE_blender_version_is_alpha) and the CMake file. Otherwise it can get out of sync if we add/rename the non-alpha release cycles. No functional change. Differential Revision: https://developer.blender.org/D13379
2021-11-26 09:33:47 +01:00
else()
set(WITH_EXPERIMENTAL_FEATURES OFF)
CMake: Force experimental features to be on/off based on release cycle 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.
2020-09-09 16:07:29 +02:00
endif()
Remove (ifdef) RNA for simulation, point cloud and particles 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
2020-08-17 09:47:10 +02:00
Cleanup: fix various typos Contributed by luzpaz. Differential Revision: https://developer.blender.org/D14203
2022-03-07 17:25:50 +01:00
# Unit testing
GTest unit testing framework Currently covers only small set of functionality.
2014-06-18 22:49:17 +10:00
option(WITH_GTESTS "Enable GTest unit testing" OFF)
Cleanup: line length in CMake files
2024-03-07 13:26:55 +11:00
option(WITH_GPU_RENDER_TESTS "\
Enable GPU render related unit testing (EEVEE, Workbench and Grease Pencil)"
OFF
)
Vulkan: Disable render tests Render tests can still fail. This change will disable them until they are in a better shape. Reduces confusion when running cycles GPU render tests. Known issues: - Render in batch can take forever due to a locking issue - Headless rendering is still in development - Particle hair rendering is broken. Pull Request: https://projects.blender.org/blender/blender/pulls/131964
2024-12-16 16:18:06 +01:00
option(WITH_GPU_RENDER_TESTS_VULKAN "\
Enable GPU render related unit testing using Vulkan"
OFF
)
mark_as_advanced(WITH_GPU_RENDER_TESTS_VULKAN)
Overlay: Add tests This adds support for Overlay tests. There are some differences with how we handle tests for other engines: - The renders are captured using `bpy.ops.render.opengl()`, but this won't work on our GPU build bots. - A single blend file can run multiple tests by outputting a txt list with the test names. - Each overlay test blend file requires a matching script file with the same name inside `tests/python/overlay/`. - To reproduce a specific test state you can run `blender "(...)/tests/data/overlay/<test>.blend" -P "(...)/tests/python/overlay/<test>.py" -- --test <test-number>`. Note: The current test permutations are WIP, so reference images are not committed to the data repo for now. Pull Request: https://projects.blender.org/blender/blender/pulls/133879
2025-02-20 17:18:59 +01:00
option(WITH_GPU_RENDER_TESTS_HEADED "\
Enable GPU render related unit testing that doesn't work in background mode. \
These tests require an environment with a display server to run. \
Requires WITH_GPU_RENDER_TESTS "
OFF
)
mark_as_advanced(WITH_GPU_RENDER_TESTS_HEADED)
GPU: Split GPU backend and Draw manager unit tests Both the draw manager and gpu backend used the same compilation directive for enablement. This PR seperates them into `WITH_GPU_DRAW_TESTS` for draw manager related tests and `WITH_GPU_BACKEND_TESTS` for gpu backend related tests. Pull Request: https://projects.blender.org/blender/blender/pulls/132018
2024-12-17 13:28:21 +01:00
option(WITH_GPU_BACKEND_TESTS "\
Enable GPU backend related unit testing"
OFF
)
Cleanup: line length in CMake files
2024-03-07 13:26:55 +11:00
option(WITH_GPU_DRAW_TESTS "\
GPU: Split GPU backend and Draw manager unit tests Both the draw manager and gpu backend used the same compilation directive for enablement. This PR seperates them into `WITH_GPU_DRAW_TESTS` for draw manager related tests and `WITH_GPU_BACKEND_TESTS` for gpu backend related tests. Pull Request: https://projects.blender.org/blender/blender/pulls/132018
2024-12-17 13:28:21 +01:00
Enable GPU drawing related unit testing (draw manager)"
Cleanup: line length in CMake files
2024-03-07 13:26:55 +11:00
OFF
)
Cleanup: Rename COMPOSITOR_REALTIME to GPU_COMPOSITOR Pull Request: https://projects.blender.org/blender/blender/pulls/132118
2024-12-19 14:39:55 +01:00
option(WITH_GPU_COMPOSITOR_TESTS "Enable regression testing for GPU compositor" OFF)
Cleanup: wrap long lines for CMake
2025-04-05 20:21:57 +11:00
option(WITH_GPU_MESH_PAINT_TESTS "\
Enable visual render-based regression testing for mesh painting"
OFF
)
Build: Allow UI tests to run locally on all platforms This commit allows the `WITH_UI_TESTS` CMake option to be used on all platforms, not only Linux. The existing functionality to use the Weston compositor was moved into the `WITH_UI_TESTS_HEADLESS` option. When these tests are run with only `WITH_UI_TESTS`, a visible instance of Blender is opened up for testing. Pull Request: https://projects.blender.org/blender/blender/pulls/135889
2025-03-14 22:27:50 +01:00
option(WITH_UI_TESTS "\
Enable user-interface tests (Experimental)"
OFF
)
Tests: support running graphical tests as part of CTests User a Blender wrapper `tests/utils/blender_headless.py` to runs a graphical instance of Blender within a headless weston compositor. Currently only WAYLAND is supported as a back-end, support for other platforms is possible. The tests can run from X11 since the tests don't depend on existing instances of X11 or WAYLAND. - Each test runs a separate headless instance of WESTON since the overhead is minimal, this allows tests to run in parallel without interfering with each other. - There is a CMake option WESTON_BIN, when left empty the weston from LIBDIR is used. Otherwise this can point to the weston binary installed on the users system. - In most cases simulated events are needed to implement these tests (running blender with `--enable-event-simulate`). - This commit adds 14 undo tests - simulating user interaction as well as undo/redo actions, ensuring the desired result is reached. Other kinds of UI tests could be added in the future. Ref !114164
2023-10-26 15:19:33 +11:00
if(UNIX AND NOT (APPLE OR HAIKU))
CMake: enable WITH_UI_TESTS_HEADLESS when possible Prefer headless tests, details in code-comments.
2025-04-02 03:02:05 +00:00
# Headless is preferable as opening windows on the developers computer
# prevents the system being used while tests run. It's also unreliable,
# where tiling compositors ignore the window size causing some tests to fail.
set(_option_default OFF)
if(WITH_GHOST_WAYLAND)
set(_option_default ON)
endif()
Build: Allow UI tests to run locally on all platforms This commit allows the `WITH_UI_TESTS` CMake option to be used on all platforms, not only Linux. The existing functionality to use the Weston compositor was moved into the `WITH_UI_TESTS_HEADLESS` option. When these tests are run with only `WITH_UI_TESTS`, a visible instance of Blender is opened up for testing. Pull Request: https://projects.blender.org/blender/blender/pulls/135889
2025-03-14 22:27:50 +01:00
option(WITH_UI_TESTS_HEADLESS "\
Tests: support running graphical tests as part of CTests User a Blender wrapper `tests/utils/blender_headless.py` to runs a graphical instance of Blender within a headless weston compositor. Currently only WAYLAND is supported as a back-end, support for other platforms is possible. The tests can run from X11 since the tests don't depend on existing instances of X11 or WAYLAND. - Each test runs a separate headless instance of WESTON since the overhead is minimal, this allows tests to run in parallel without interfering with each other. - There is a CMake option WESTON_BIN, when left empty the weston from LIBDIR is used. Otherwise this can point to the weston binary installed on the users system. - In most cases simulated events are needed to implement these tests (running blender with `--enable-event-simulate`). - This commit adds 14 undo tests - simulating user interaction as well as undo/redo actions, ensuring the desired result is reached. Other kinds of UI tests could be added in the future. Ref !114164
2023-10-26 15:19:33 +11:00
Enable user-interface tests using a headless display server. \
Currently this depends on WITH_GHOST_WAYLAND and the weston compositor \
(Experimental)"
CMake: enable WITH_UI_TESTS_HEADLESS when possible Prefer headless tests, details in code-comments.
2025-04-02 03:02:05 +00:00
${_option_default}
Tests: support running graphical tests as part of CTests User a Blender wrapper `tests/utils/blender_headless.py` to runs a graphical instance of Blender within a headless weston compositor. Currently only WAYLAND is supported as a back-end, support for other platforms is possible. The tests can run from X11 since the tests don't depend on existing instances of X11 or WAYLAND. - Each test runs a separate headless instance of WESTON since the overhead is minimal, this allows tests to run in parallel without interfering with each other. - There is a CMake option WESTON_BIN, when left empty the weston from LIBDIR is used. Otherwise this can point to the weston binary installed on the users system. - In most cases simulated events are needed to implement these tests (running blender with `--enable-event-simulate`). - This commit adds 14 undo tests - simulating user interaction as well as undo/redo actions, ensuring the desired result is reached. Other kinds of UI tests could be added in the future. Ref !114164
2023-10-26 15:19:33 +11:00
)
CMake: enable WITH_UI_TESTS_HEADLESS when possible Prefer headless tests, details in code-comments.
2025-04-02 03:02:05 +00:00
unset(_option_default)
Tests: Add sanity check test for Linux releases This test does some rudimentary checks to see if the binaries and folder structure are ready for a release. Pull Request: https://projects.blender.org/blender/blender/pulls/130319
2024-11-15 18:12:52 +01:00
option(WITH_LINUX_OFFICIAL_RELEASE_TESTS "\
Enable sanity check tests for the linux official release. \
Cleanup: spelling in comments (make check_spelling_*)
2025-04-02 03:02:01 +00:00
These test are only relevant for checking that our official Linux releases are portable and \
Tests: Add sanity check test for Linux releases This test does some rudimentary checks to see if the binaries and folder structure are ready for a release. Pull Request: https://projects.blender.org/blender/blender/pulls/130319
2024-11-15 18:12:52 +01:00
packaged properly. For example that we don't link to any unexpected system libraries."
OFF
)
Tests: support running graphical tests as part of CTests User a Blender wrapper `tests/utils/blender_headless.py` to runs a graphical instance of Blender within a headless weston compositor. Currently only WAYLAND is supported as a back-end, support for other platforms is possible. The tests can run from X11 since the tests don't depend on existing instances of X11 or WAYLAND. - Each test runs a separate headless instance of WESTON since the overhead is minimal, this allows tests to run in parallel without interfering with each other. - There is a CMake option WESTON_BIN, when left empty the weston from LIBDIR is used. Otherwise this can point to the weston binary installed on the users system. - In most cases simulated events are needed to implement these tests (running blender with `--enable-event-simulate`). - This commit adds 14 undo tests - simulating user interaction as well as undo/redo actions, ensuring the desired result is reached. Other kinds of UI tests could be added in the future. Ref !114164
2023-10-26 15:19:33 +11:00
else()
Build: Allow UI tests to run locally on all platforms This commit allows the `WITH_UI_TESTS` CMake option to be used on all platforms, not only Linux. The existing functionality to use the Weston compositor was moved into the `WITH_UI_TESTS_HEADLESS` option. When these tests are run with only `WITH_UI_TESTS`, a visible instance of Blender is opened up for testing. Pull Request: https://projects.blender.org/blender/blender/pulls/135889
2025-03-14 22:27:50 +01:00
set(WITH_UI_TESTS_HEADLESS OFF)
Cleanup: spelling in comments (make check_spelling_*)
2025-04-02 03:02:01 +00:00
# TODO: We should probably add more sanity checks for Windows and Mac as well
Tests: Add sanity check test for Linux releases This test does some rudimentary checks to see if the binaries and folder structure are ready for a release. Pull Request: https://projects.blender.org/blender/blender/pulls/130319
2024-11-15 18:12:52 +01:00
set(WITH_LINUX_OFFICIAL_RELEASE_TESTS OFF)
Tests: support running graphical tests as part of CTests User a Blender wrapper `tests/utils/blender_headless.py` to runs a graphical instance of Blender within a headless weston compositor. Currently only WAYLAND is supported as a back-end, support for other platforms is possible. The tests can run from X11 since the tests don't depend on existing instances of X11 or WAYLAND. - Each test runs a separate headless instance of WESTON since the overhead is minimal, this allows tests to run in parallel without interfering with each other. - There is a CMake option WESTON_BIN, when left empty the weston from LIBDIR is used. Otherwise this can point to the weston binary installed on the users system. - In most cases simulated events are needed to implement these tests (running blender with `--enable-event-simulate`). - This commit adds 14 undo tests - simulating user interaction as well as undo/redo actions, ensuring the desired result is reached. Other kinds of UI tests could be added in the future. Ref !114164
2023-10-26 15:19:33 +11:00
endif()
CMake: Rename and expose 'USE_EXPERIMENTAL_TESTS' option The `USE_EXPERIMENTAL_TESTS` variable was not exposed as an option, so the two tests that use the option to check whether tests should be run had to be manually enabled by changing `tests/python/CMakeLists.txt`. This commit renames the variable to `WITH_TESTS_EXPERIMENTAL`, defaults the option to `OFF`, and marks it as an advanced option. Pull Request: https://projects.blender.org/blender/blender/pulls/133831
2025-04-24 06:11:30 +02:00
option(WITH_TESTS_EXPERIMENTAL "\
Run tests marked as experimental. \
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
These tests are labeled as such due to long runtime, flakey results,
or other issues that make them unsuitable for blocking a build on."
CMake: Rename and expose 'USE_EXPERIMENTAL_TESTS' option The `USE_EXPERIMENTAL_TESTS` variable was not exposed as an option, so the two tests that use the option to check whether tests should be run had to be manually enabled by changing `tests/python/CMakeLists.txt`. This commit renames the variable to `WITH_TESTS_EXPERIMENTAL`, defaults the option to `OFF`, and marks it as an advanced option. Pull Request: https://projects.blender.org/blender/blender/pulls/133831
2025-04-24 06:11:30 +02:00
OFF
)
mark_as_advanced(WITH_TESTS_EXPERIMENTAL)
Tests: add WIITH_TESTS_BATCHED option to execute Blender once per test Some tests like cycles, sequencer and compositor batch together multiple tests in a single Blender invocation. This makes them run faster, but makes debugging harder. This is an option to disable that batching. Pull Request: https://projects.blender.org/blender/blender/pulls/114603
2023-11-08 18:41:33 +01:00
# Enabled by default for typical use cases to speed up development cycles. However, when looking
# into threading or memory related issues (in dependency graph, out-of-bounds, etc) forcing single
# test per Blender instance could give much better clues about the root of the problem.
Cleanup: line length in CMake files
2024-03-07 13:26:55 +11:00
option(WITH_TESTS_BATCHED "\
Run multiple tests in a single Blender invocation, for faster test execution"
ON
)
Tests: add WIITH_TESTS_BATCHED option to execute Blender once per test Some tests like cycles, sequencer and compositor batch together multiple tests in a single Blender invocation. This makes them run faster, but makes debugging harder. This is an option to disable that batching. Pull Request: https://projects.blender.org/blender/blender/pulls/114603
2023-11-08 18:41:33 +01:00
mark_as_advanced(WITH_TESTS_BATCHED)
Tests: add option to build one binary per GTest file 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
2024-01-03 18:35:50 +01:00
option(WITH_TESTS_SINGLE_BINARY "\
Link GTest tests into a single binary. \
For faster overall build and less disk space, but slower individual test build"
ON
)
mark_as_advanced(WITH_TESTS_SINGLE_BINARY)
Tests: don't create byte-code cache when calling Python from SVN Creating `__pycache__` directories in SVN's lib/ directory can cause updating SVN to fail. Add the -B flag when TEST_PYTHON_EXE from LIBDIR is used so so Python doesn't generate this cache.
2022-11-03 11:48:47 +11:00
# NOTE: All callers of this must add `TEST_PYTHON_EXE_EXTRA_ARGS` before any other arguments.
Tests: use explicit Python to run unit tests CentOS on the buildbot still runs Python 3.6, which is also used for the unit tests. This means that the tests can't use language features that are available to Blender itself. And testing with a different version of Python than will be used by the actual code seems like a bad idea to me. This commit adds `TEST_PYTHON_EXECUTABLE` as advanced CMake option. This will allow us to set a specific Python executable when we need it. When not set, a platform-specific default will be used: - On Windows, the `python….exe` from the installation directory. This is just like before this patch, except that this patch adds the overridability. - On macOS/Linux, the `${PYTHON_EXECUTABLE}` as found by CMake. Every platform should now have a value (configured by the user or detected by CMake) for `TEST_PYTHON_EXE`, so there is no need to allow running without. This also removes the need to have some Python files marked as executable. If `TEST_PYTHON_EXE` is not user-configured, and thus the above default is used, a status message is logged by CMake. I've seen this a lot in other projects, and I like that it shows which values are auto-detected. However, it's not common in Blender, so if we want we can either remove it now, or remove it after the buildbot has been set up correctly. Differential Revision: https://developer.blender.org/D7395 Reviewed by: campbellbarton, mont29, sergey
2020-04-10 10:35:17 +02:00
set(TEST_PYTHON_EXE "" CACHE PATH "Python executable to run unit tests")
mark_as_advanced(TEST_PYTHON_EXE)
GTest unit testing framework Currently covers only small set of functionality.
2014-06-18 22:49:17 +10:00
Add 'system python' validation for some py scripts. The goal of this test is to try to import some critical py scripts with the system python of the building machine. The main target is to ensure that these py scripts remain usable by all buildbot machines, as some of them are using fairly outdated python versions. Current status: * Scripts in `build_files` and `docs` are checked. * Some python scripts in `build_files` were 'reverted' to be compatible with older required python version currently (3.6). * A few scripts are excluded from the test, mostly because they use Blender's `bpy` module, which means they are only intended to be ran with Blender's python anyway. * The test is only enabled for Linux buildbots currently, as they use the oldest Python by far. Notes: * Some more scripts are likely to be moved around in the future. * Whether these tests need to be enabled on windows or macos platforms remains an open question. Pull Request: https://projects.blender.org/blender/blender/pulls/130746
2024-12-24 11:55:29 +01:00
# System python tests.
option(WITH_SYSTEM_PYTHON_TESTS "\
Enable tests validating some build-related scripts against the 'system' version of Python \
(buildbots currently can use significantly older versions of Python than Blender's)"
OFF
)
mark_as_advanced(WITH_SYSTEM_PYTHON_TESTS)
# We could use `find_package (Python3 COMPONENTS Interpreter)` to set that value automatically.
Cleanup: wrap long lines for CMake
2025-04-05 20:21:57 +11:00
# However, on some buildbots this will give the default Python version of the current virtual
# environment, which may differ from the OS default Python version.
# And it would set that global 'python3 exec path' CMake value for all CMake scripts,
# which could have unexpected and dangerous side effects.
Cleanup: Spelling: "Explicitly"
2025-01-03 22:33:33 -05:00
# So this has to be set explicitly for all builders.
Add 'system python' validation for some py scripts. The goal of this test is to try to import some critical py scripts with the system python of the building machine. The main target is to ensure that these py scripts remain usable by all buildbot machines, as some of them are using fairly outdated python versions. Current status: * Scripts in `build_files` and `docs` are checked. * Some python scripts in `build_files` were 'reverted' to be compatible with older required python version currently (3.6). * A few scripts are excluded from the test, mostly because they use Blender's `bpy` module, which means they are only intended to be ran with Blender's python anyway. * The test is only enabled for Linux buildbots currently, as they use the oldest Python by far. Notes: * Some more scripts are likely to be moved around in the future. * Whether these tests need to be enabled on windows or macos platforms remains an open question. Pull Request: https://projects.blender.org/blender/blender/pulls/130746
2024-12-24 11:55:29 +01:00
set(TEST_SYSTEM_PYTHON_EXE "" CACHE PATH "Python executable used to run 'system python' tests")
mark_as_advanced(TEST_SYSTEM_PYTHON_EXE)
CMake: manpage creation is now optional
2014-11-13 14:07:34 +01:00
# Documentation
if(UNIX AND NOT APPLE)
option(WITH_DOC_MANPAGE "Create a manual page (Unix manpage)" OFF)
endif()
GHOST: Replace WITH_OPENGL build option Replaces it by WITH_OPENGL_BACKEND and cleanup its usage. Limits visibility of opengl enums and cases. Pull Request: https://projects.blender.org/blender/blender/pulls/109947
2023-07-11 09:17:31 +02:00
# GPU Module
GPU: Renderdoc Frame Capturing This PR uses renderdoc for frame capturing when enabled. It enabled an easier workflow for frame capturing. - Capture GPU API calls from test cases - Capture GPU API calls from background threads - Capture GPU API calls from background rendering. Renderdoc is an important GPU debugger used by the Eevee/ Viewport module. Previously we needed to change code in order to record background rendering, that could on its own lead to other side-effects. The integration with renderdoc can be enabled using `WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin` and `GPU_debug_capture_end` can be added to the section of the code you want to debug. When running Blender inside renderdoc this part will automatically be captured. All GPU test cases are now guarded by these calls. In order to capture the test cases you need to start the test cases from renderdoc and the captured GPU API calls will appear where each capture is a single test case. Pull Request: https://projects.blender.org/blender/blender/pulls/105921
2023-03-23 16:37:52 +01:00
option(WITH_RENDERDOC "Use Renderdoc API to capture frames" OFF)
Ghost Context Refactor https://developer.blender.org/D643 Separates graphics context creation from window code in Ghost so that they can vary separately.
2014-10-07 15:46:19 -05:00
GPU: Add support for shader assert This allows to use `assert()` directly inside shader source. The current implementation is just replacing it with a printf that gives some information about the location of the assert. It is not that much more helpful than a printf with a condition. What is useful is that they are disabled by default. So they can be sprinkle around and only turned on during debugging. Adding shader name inside the assert report is not trivial and could be added later (the shader name is only known at compile time which is too late for string parsing). Adding which drawcall produced the assert isn't trivial either. It would require flushing the printf buffer for each drawcall which might force synchronization and remove bugs. Pull Request: https://projects.blender.org/blender/blender/pulls/129728
2024-11-06 20:29:01 +01:00
option(WITH_GPU_SHADER_ASSERT "\
Globally enable in-shader asserts.
(Requires a debug build or setting GPU_FORCE_ENABLE_SHADER_PRINTF to 1)"
OFF
)
Ghost Context Refactor https://developer.blender.org/D643 Separates graphics context creation from window code in Ghost so that they can vary separately.
2014-10-07 15:46:19 -05:00
mark_as_advanced(
GPU: Renderdoc Frame Capturing This PR uses renderdoc for frame capturing when enabled. It enabled an easier workflow for frame capturing. - Capture GPU API calls from test cases - Capture GPU API calls from background threads - Capture GPU API calls from background rendering. Renderdoc is an important GPU debugger used by the Eevee/ Viewport module. Previously we needed to change code in order to record background rendering, that could on its own lead to other side-effects. The integration with renderdoc can be enabled using `WITH_RENDERDOC=On` compiler option. `GPU_debug_capture_begin` and `GPU_debug_capture_end` can be added to the section of the code you want to debug. When running Blender inside renderdoc this part will automatically be captured. All GPU test cases are now guarded by these calls. In order to capture the test cases you need to start the test cases from renderdoc and the captured GPU API calls will appear where each capture is a single test case. Pull Request: https://projects.blender.org/blender/blender/pulls/105921
2023-03-23 16:37:52 +01:00
WITH_RENDERDOC
GPU: Add support for shader assert This allows to use `assert()` directly inside shader source. The current implementation is just replacing it with a printf that gives some information about the location of the assert. It is not that much more helpful than a printf with a condition. What is useful is that they are disabled by default. So they can be sprinkle around and only turned on during debugging. Adding shader name inside the assert report is not trivial and could be added later (the shader name is only known at compile time which is too late for string parsing). Adding which drawcall produced the assert isn't trivial either. It would require flushing the printf buffer for each drawcall which might force synchronization and remove bugs. Pull Request: https://projects.blender.org/blender/blender/pulls/129728
2024-11-06 20:29:01 +01:00
WITH_GPU_SHADER_ASSERT
Ghost Context Refactor https://developer.blender.org/D643 Separates graphics context creation from window code in Ghost so that they can vary separately.
2014-10-07 15:46:19 -05:00
)
GPU: GLSL compilation as C++ for gpu static shaders Allow compilation of shaders using C++ for linting and IDE support. Related #127983 Pull Request: https://projects.blender.org/blender/blender/pulls/128724
2024-11-12 18:53:34 +01:00
if(POLICY CMP0119)
option(WITH_GPU_SHADER_CPP_COMPILATION "\
Compiler shaders using C++. \
Allows testing Metal compilation on other platform and enable C++ IDE support for shader code"
Cleanup: correct indentation for CMake files, strip trailing space
2025-01-03 13:23:38 +11:00
OFF
GPU: GLSL compilation as C++ for gpu static shaders Allow compilation of shaders using C++ for linting and IDE support. Related #127983 Pull Request: https://projects.blender.org/blender/blender/pulls/128724
2024-11-12 18:53:34 +01:00
)
mark_as_advanced(WITH_GPU_SHADER_CPP_COMPILATION)
else()
set(WITH_GPU_SHADER_CPP_COMPILATION OFF)
endif()
GHOST: Replace WITH_OPENGL build option Replaces it by WITH_OPENGL_BACKEND and cleanup its usage. Limits visibility of opengl enums and cases. Pull Request: https://projects.blender.org/blender/blender/pulls/109947
2023-07-11 09:17:31 +02:00
# OpenGL
GHOST: Delete Mac OpenGL support The maximum OpenGL versions supported on mac doesn't meet the minimum required version (>=4.3) anymore. This removes all the OpenGL paths in GHOST Cocoa backend and from the drop down menu in the user preferences. Pull Request: https://projects.blender.org/blender/blender/pulls/110185
2023-07-19 14:16:03 +02:00
if(NOT APPLE)
option(WITH_OPENGL_BACKEND "Enable OpenGL support as graphic backend" ON)
mark_as_advanced(WITH_OPENGL_BACKEND)
else()
set(WITH_OPENGL_BACKEND OFF)
endif()
GHOST: Replace WITH_OPENGL build option Replaces it by WITH_OPENGL_BACKEND and cleanup its usage. Limits visibility of opengl enums and cases. Pull Request: https://projects.blender.org/blender/blender/pulls/109947
2023-07-11 09:17:31 +02:00
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
# Vulkan
Vulkan: Remove MoltenVK Blender had some support for using MoltenVK. However there are some key issues why MotlenVK cannot be used. Bugs have been reported up-stream. As it doesn't work and holds back regular developments it will be removed from the main branch. Any efforts on making Vulkan run on Apple (including KosmicKrisp) is considered a community effort and can be done in a development branch. Pull Request: https://projects.blender.org/blender/blender/pulls/144602
2025-08-15 09:36:38 +02:00
if(NOT APPLE)
option(WITH_VULKAN_BACKEND "Enable Vulkan as graphics backend" ON)
mark_as_advanced(WITH_VULKAN_BACKEND)
else()
Vulkan: MoltenVK Support for Developers MoltenVK original intent was to let developers work on a mac system developing for the vulkan eco-system. MoltenVK doesn't support all the features that we require and would require additional workarounds to be actually supported. It is not expected that we will release Blender with MoltenVK for this reason. But it still has value for shader developers to validate shaders on metal and vulkan on a single platform. ![image](/attachments/9a4a9904-a5f6-4922-896d-744dfb78244c) Pull Request: https://projects.blender.org/blender/blender/pulls/117940
2024-04-11 11:04:43 +02:00
set(WITH_VULKAN_BACKEND OFF)
endif()
GPU: Add placeholder for Vulkan backend. This patch adds a placeholder for the vulkan backend. When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`) it might open a blender screen, but nothing should be visible as none of the functions are implemented or otherwise crash on a nullptr. This is expected as this is just a placeholder. The goal is to add shader compilation +validation to this backend as one of the next steps so we can validate changes to existing shaders on OpenGL, Metal and Vulkan at the same time. Reviewed By: fclem Differential Revision: https://developer.blender.org/D16338
2022-10-31 16:01:02 +01:00
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
# Metal
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
if(APPLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_METAL_BACKEND "\
Use Metal for graphics instead of (or as well as) OpenGL on macOS."
ON
)
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
mark_as_advanced(WITH_METAL_BACKEND)
else()
set(WITH_METAL_BACKEND OFF)
endif()
CMake: make install prefix option irrelevant for MinGW too.
2015-12-27 16:57:31 +01:00
if(WIN32)
cmake buildfiles Cleanup / Refactor, no functional changes. Move away from using hardcoded ${target} when calling install() in cmake
2014-11-08 11:32:32 +01:00
getDefaultWindowsPrefixBase(CMAKE_GENERIC_PROGRAM_FILES)
set(CPACK_INSTALL_PREFIX ${CMAKE_GENERIC_PROGRAM_FILES}/${})
endif()
CMake: add WITH_STRSIZE_DEBUG option, RNA support Support string size debug so it can be used for regular development. It works be writing values into strings, ensuring the buffer size given is actually available. Developers can use this with memory checking tools such as ASAN/valgrind to force an error when the value used for the size of a buffer is larger than the buffer. Resolve remaining issue with RNA using BLI_strncpy* in generated callback functions where the size argument didn't represent the size of the destination buffer. This is automatically enabled along with ASAN for the blender_developer.cmake configuration. Ref PR !107602.
2023-05-07 13:32:46 +10:00
option(WITH_STRSIZE_DEBUG "\
Ensure string operations on fixed size buffers \
Cleanup: spelling & duplicate terms (check_spelling.py)
2025-05-30 10:59:58 +10:00
(works well with \"WITH_COMPILER_ASAN\" & valgrind to detect incorrect buffer size arguments)"
CMake: add WITH_STRSIZE_DEBUG option, RNA support Support string size debug so it can be used for regular development. It works be writing values into strings, ensuring the buffer size given is actually available. Developers can use this with memory checking tools such as ASAN/valgrind to force an error when the value used for the size of a buffer is larger than the buffer. Resolve remaining issue with RNA using BLI_strncpy* in generated callback functions where the size argument didn't represent the size of the destination buffer. This is automatically enabled along with ASAN for the blender_developer.cmake configuration. Ref PR !107602.
2023-05-07 13:32:46 +10:00
OFF)
mark_as_advanced(WITH_STRSIZE_DEBUG)
Revert "BLI: Refactor vector types & functions to use templates" Includes unwanted changes This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
2022-01-12 12:49:36 +01:00
# Compiler tool-chain.
Build: Remove macOS mold and lld linkers support The mold linker doesn't support macOS anymore. The sold linker gets no new releases since the Xcode 15+ linker is at par with sold. https://github.com/bluewhalesystems/sold/issues/50#issuecomment-2076249631 https://github.com/rui314/mold/issues/189#issuecomment-1495288926 Pull Request: https://projects.blender.org/blender/blender/pulls/133634
2025-01-30 18:21:38 +01:00
if(UNIX AND NOT APPLE)
Revert "BLI: Refactor vector types & functions to use templates" Includes unwanted changes This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
2022-01-12 12:49:36 +01:00
if(CMAKE_COMPILER_IS_GNUCC)
option(WITH_LINKER_GOLD "Use ld.gold linker which is usually faster than ld.bfd" ON)
mark_as_advanced(WITH_LINKER_GOLD)
endif()
Unbreak build on macOS with AppleClang from recent cleanup Exact an exact match with Clang broke building when the compiler ID was "AppleClang", reverting parts of [0]. [0]: 6549019ae19cecbea524782054dca0e99cb833b8
2024-03-07 19:56:58 +11:00
if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID MATCHES "Clang")
macOS/Linker: support mold and lld If someone buys "sold", mold should work on macOS too. With lld, Blender (700 MB) intel i5: 26s -> 17s. Pull Request #106843
2023-04-12 17:01:53 +05:30
option(WITH_LINKER_LLD "Use ld.lld linker which is usually faster than ld.gold" OFF)
mark_as_advanced(WITH_LINKER_LLD)
macOS: remove note about sold linker, mold 2.0 is now free on macOS
2023-08-01 12:35:13 +02:00
option(WITH_LINKER_MOLD "Use ld.mold linker which is usually faster than ld.gold & ld.lld" OFF)
CMake: add WITH_LINKER_MOLD option for GCC/Clang Unix platforms Can give considerably faster linking, especially on system with many cores. The mold linker recently reached 1.0, see: https://github.com/rui314/mold The current stable release of GCC can't use this linker via -fuse-ld=mold, so this patch uses the "-B" argument to add a binary directory containing an alternate "ld" command that points to "mold" (which is part of the default mold installation). Some timing tests for linking full builds for AMD TR 3970X: - BFD: 20.78 seconds. - LLD: 12.16 seconds. - GOLD: 7.21 seconds. - MOLD: 2.53 seconds. Ref D13807 Reviewed by: sergey, brecht
2022-01-12 13:35:07 +11:00
mark_as_advanced(WITH_LINKER_MOLD)
endif()
CMake: Make ld.gold linker optional Some platforms are having hard time using this linker so added an option to not use it. The options is an advanced one and enabled by default so should not cause any changes for current users.
2016-11-02 10:42:15 +01:00
endif()
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_COMPILER_ASAN "\
Build and link against address sanitizer (only for Debug & RelWithDebInfo targets)."
OFF
)
MSVC: ASAN support for VS 16.9 This enables ASAN support when used with VS 16.9 enable as usual in cmake with the WITH_COMPILER_ASAN option, or when using make.bat just tag on `asan' to the invocation, ie: `make lite 2019 asan` MSVC: Asan support for 16.9 This enables ASAN support when used with VS 16.9 enable as usual in cmake with the WITH_COMPILER_ASAN option, or when using make.bat just tag on `asan' to the invocation, ie: `make lite 2019 asan` Differential Revision: https://developer.blender.org/D7794 Reviewed By: brecht, sergey
2021-03-29 19:11:17 -06:00
mark_as_advanced(WITH_COMPILER_ASAN)
Fix linking errors when doing full debug build with ASAN: Disable ASAN for `extern`. With current main code, trying to build a full debug build with ASAN enabled will fail at linking, due to out-of-bound memory references within the binary file, e.g.: ``` mold: error: /usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o:(.text): relocation R_X86_64_32S against .tm_clone_table out of range: 2147741344 is not in [-2147483648, 2147483648) ``` This commit works around the issue by disabling ASAN by default for the `extern` dependencies. A new `WITH_COMPILER_ASAN_EXTERN` CMake option is added to enable it if needed - some other components need to be disabled then. NOTE: This is more of an emergency band-aid to the general binary size issue, see #113892 for on-going discussions about better solutions in the long term. Pull Request: https://projects.blender.org/blender/blender/pulls/113891
2023-10-19 11:07:06 +02:00
option(WITH_COMPILER_ASAN_EXTERN "\
Build `extern` dependencies with address sanitizer when WITH_COMPILER_ASAN is on. \
Can cause linking issues due to too large binary size."
OFF
)
CMake: mark WITH_COMPILER_ASAN_EXTERN as advanced, quiet warning
2023-10-31 10:42:06 +11:00
mark_as_advanced(WITH_COMPILER_ASAN_EXTERN)
Fix: CMake: Disable jemalloc/valgrind when ASAN options are enabled. These are incompatible with eachother. ASAN takes over, as it is disabled by default, while jemalloc is enabled by default. Pull Request: https://projects.blender.org/blender/blender/pulls/131158
2024-11-29 15:35:37 +01:00
set_and_warn_incompatible(WITH_COMPILER_ASAN WITH_MEM_JEMALLOC OFF)
set_and_warn_incompatible(WITH_COMPILER_ASAN WITH_MEM_VALGRIND OFF)
set_and_warn_incompatible(WITH_COMPILER_ASAN_EXTERN WITH_MEM_JEMALLOC OFF)
set_and_warn_incompatible(WITH_COMPILER_ASAN_EXTERN WITH_MEM_VALGRIND OFF)
CMake: Add WITH_COMPILER_ASAN option This supports easy toggling of Address Sanitizer.
2018-05-18 15:21:18 +02:00
Tests: support generating code coverage report This only works with GCC and has only been tested on Linux. The main goal is to automatically generate the code coverage reports on the buildbot and to publish them. With some luck, this motivates people to increase test coverage in their respective areas. Nevertheless, it should be easy to generate the reports locally too (at least on supported software stacks). Usage: 1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE** enabled. 2. Run tests. This automatically generates `.gcda` files in the build directory. 3. Run `make/ninja coverage-report` in the build directory. If everything is successful, this will open a browser with the final report which is stored in `build-dir/coverage/report/`. For a bit more control one can also run `coverage.py` script directly. This allows passing in the `--no-browser` option which may be benefitial when running it on the buildbot. Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the line execution counts. The final report has a main entry point (`index.html`) and a separate `.html` file for every source code file that coverage data was available for. This also contains some code that is not in Blender's git repository. We could filter those out, but it also seems interesting (to me anyway), so I just kept it in. Doing the analysis and writing the report takes ~1 min. The slow part is running all tests in a debug build which takes ~12 min for me. Since the coverage data is fairly large and the report also includes the entire source code, file compression is used in two places: * The intermediate analysis results for each file are stored in compressed zip files. This data is still independent from the report html and could be used to build other tools on top of. I could imagine storing the analysis data for each day for example to gather greater insights into how coverage changes over time in different parts of the code. * The analysis data and source code is compressed and base64 encoded embedded into the `.html` files. This makes them much smaller than embedding the data without compression (5-10x). Pull Request: https://projects.blender.org/blender/blender/pulls/126181
2024-08-15 12:17:55 +02:00
option(WITH_COMPILER_CODE_COVERAGE "\
Build and link with code coverage support (only for Debug targets)."
Cleanup: correct indentation for CMake files, strip trailing space
2025-01-03 13:23:38 +11:00
OFF
Tests: support generating code coverage report This only works with GCC and has only been tested on Linux. The main goal is to automatically generate the code coverage reports on the buildbot and to publish them. With some luck, this motivates people to increase test coverage in their respective areas. Nevertheless, it should be easy to generate the reports locally too (at least on supported software stacks). Usage: 1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE** enabled. 2. Run tests. This automatically generates `.gcda` files in the build directory. 3. Run `make/ninja coverage-report` in the build directory. If everything is successful, this will open a browser with the final report which is stored in `build-dir/coverage/report/`. For a bit more control one can also run `coverage.py` script directly. This allows passing in the `--no-browser` option which may be benefitial when running it on the buildbot. Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the line execution counts. The final report has a main entry point (`index.html`) and a separate `.html` file for every source code file that coverage data was available for. This also contains some code that is not in Blender's git repository. We could filter those out, but it also seems interesting (to me anyway), so I just kept it in. Doing the analysis and writing the report takes ~1 min. The slow part is running all tests in a debug build which takes ~12 min for me. Since the coverage data is fairly large and the report also includes the entire source code, file compression is used in two places: * The intermediate analysis results for each file are stored in compressed zip files. This data is still independent from the report html and could be used to build other tools on top of. I could imagine storing the analysis data for each day for example to gather greater insights into how coverage changes over time in different parts of the code. * The analysis data and source code is compressed and base64 encoded embedded into the `.html` files. This makes them much smaller than embedding the data without compression (5-10x). Pull Request: https://projects.blender.org/blender/blender/pulls/126181
2024-08-15 12:17:55 +02:00
)
mark_as_advanced(WITH_COMPILER_CODE_COVERAGE)
if(WITH_COMPILER_CODE_COVERAGE)
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
if(CMAKE_COMPILER_IS_GNUCC)
set(_code_coverage_defaults "--coverage")
elseif(CMAKE_C_COMPILER_ID MATCHES "Clang")
get_filename_component(COMPILER_DIRECTORY ${CMAKE_CXX_COMPILER} DIRECTORY)
find_program(LLVM_COV "llvm-cov" ${COMPILER_DIRECTORY} NO_DEFAULT_PATH)
find_program(LLVM_PROFDATA "llvm-profdata" ${COMPILER_DIRECTORY} NO_DEFAULT_PATH)
if(NOT LLVM_COV OR NOT LLVM_PROFDATA)
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
message(WARNING
"Could not find code coverage tools, disabling code coverage. "
"You may explicitly specify LLVM_COV and LLVM_PROFDATA to work around this warning."
)
set(WITH_COMPILER_CODE_COVERAGE OFF)
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
else()
set(_code_coverage_defaults "-fprofile-instr-generate -fcoverage-mapping")
endif()
else()
CMake: use "mode" argument for messages While it's optional, include by convention and helps to clarify the purpose of a message.
2025-05-20 11:15:35 +10:00
message(WARNING
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
"Unsupported compiler ${CMAKE_C_COMPILER_ID} for WITH_COMPILER_CODE_COVERAGE, disabling."
CMake: use "mode" argument for messages While it's optional, include by convention and helps to clarify the purpose of a message.
2025-05-20 11:15:35 +10:00
)
Tests: support generating code coverage report This only works with GCC and has only been tested on Linux. The main goal is to automatically generate the code coverage reports on the buildbot and to publish them. With some luck, this motivates people to increase test coverage in their respective areas. Nevertheless, it should be easy to generate the reports locally too (at least on supported software stacks). Usage: 1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE** enabled. 2. Run tests. This automatically generates `.gcda` files in the build directory. 3. Run `make/ninja coverage-report` in the build directory. If everything is successful, this will open a browser with the final report which is stored in `build-dir/coverage/report/`. For a bit more control one can also run `coverage.py` script directly. This allows passing in the `--no-browser` option which may be benefitial when running it on the buildbot. Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the line execution counts. The final report has a main entry point (`index.html`) and a separate `.html` file for every source code file that coverage data was available for. This also contains some code that is not in Blender's git repository. We could filter those out, but it also seems interesting (to me anyway), so I just kept it in. Doing the analysis and writing the report takes ~1 min. The slow part is running all tests in a debug build which takes ~12 min for me. Since the coverage data is fairly large and the report also includes the entire source code, file compression is used in two places: * The intermediate analysis results for each file are stored in compressed zip files. This data is still independent from the report html and could be used to build other tools on top of. I could imagine storing the analysis data for each day for example to gather greater insights into how coverage changes over time in different parts of the code. * The analysis data and source code is compressed and base64 encoded embedded into the `.html` files. This makes them much smaller than embedding the data without compression (5-10x). Pull Request: https://projects.blender.org/blender/blender/pulls/126181
2024-08-15 12:17:55 +02:00
set(WITH_COMPILER_CODE_COVERAGE OFF)
endif()
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
# The code above could have disabled the feature, so check again.
if(WITH_COMPILER_CODE_COVERAGE)
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
set(COMPILER_CODE_COVERAGE_CFLAGS
${_code_coverage_defaults} CACHE STRING
"C flags for code coverage"
)
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
mark_as_advanced(COMPILER_CODE_COVERAGE_CFLAGS)
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
set(COMPILER_CODE_COVERAGE_CXXFLAGS
${_code_coverage_defaults} CACHE STRING
"C++ flags for code coverage"
)
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
mark_as_advanced(COMPILER_CODE_COVERAGE_CXXFLAGS)
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
set(_code_coverage_dir_default "${CMAKE_BINARY_DIR}/coverage")
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
set(COMPILER_CODE_COVERAGE_DATA_DIR ${_code_coverage_dir_default} CACHE STRING
"Directory for code coverage data"
)
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
mark_as_advanced(COMPILER_CODE_COVERAGE_DATA_DIR)
unset(_code_coverage_dir_default)
endif()
unset(_code_coverage_defaults)
endif()
Tests: support generating code coverage report This only works with GCC and has only been tested on Linux. The main goal is to automatically generate the code coverage reports on the buildbot and to publish them. With some luck, this motivates people to increase test coverage in their respective areas. Nevertheless, it should be easy to generate the reports locally too (at least on supported software stacks). Usage: 1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE** enabled. 2. Run tests. This automatically generates `.gcda` files in the build directory. 3. Run `make/ninja coverage-report` in the build directory. If everything is successful, this will open a browser with the final report which is stored in `build-dir/coverage/report/`. For a bit more control one can also run `coverage.py` script directly. This allows passing in the `--no-browser` option which may be benefitial when running it on the buildbot. Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the line execution counts. The final report has a main entry point (`index.html`) and a separate `.html` file for every source code file that coverage data was available for. This also contains some code that is not in Blender's git repository. We could filter those out, but it also seems interesting (to me anyway), so I just kept it in. Doing the analysis and writing the report takes ~1 min. The slow part is running all tests in a debug build which takes ~12 min for me. Since the coverage data is fairly large and the report also includes the entire source code, file compression is used in two places: * The intermediate analysis results for each file are stored in compressed zip files. This data is still independent from the report html and could be used to build other tools on top of. I could imagine storing the analysis data for each day for example to gather greater insights into how coverage changes over time in different parts of the code. * The analysis data and source code is compressed and base64 encoded embedded into the `.html` files. This makes them much smaller than embedding the data without compression (5-10x). Pull Request: https://projects.blender.org/blender/blender/pulls/126181
2024-08-15 12:17:55 +02:00
endif()
Unbreak build on macOS with AppleClang from recent cleanup Exact an exact match with Clang broke building when the compiler ID was "AppleClang", reverting parts of [0]. [0]: 6549019ae19cecbea524782054dca0e99cb833b8
2024-03-07 19:56:58 +11:00
if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID MATCHES "Clang")
CMake: Add WITH_COMPILER_ASAN option This supports easy toggling of Address Sanitizer.
2018-05-18 15:21:18 +02:00
if(WITH_COMPILER_ASAN)
set(_asan_defaults "\
-fsanitize=address \
-fsanitize=bool \
-fsanitize=bounds \
-fsanitize=enum \
-fsanitize=float-cast-overflow \
-fsanitize=float-divide-by-zero \
-fsanitize=nonnull-attribute \
-fsanitize=returns-nonnull-attribute \
-fsanitize=signed-integer-overflow \
-fsanitize=undefined \
-fsanitize=vla-bound \
-fno-sanitize=alignment \
")
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
if(MSVC)
# clang-cl doesn't support all sanitizers, but leak and object-size give errors/warnings.
set(_asan_defaults "${_asan_defaults}")
elseif(APPLE)
# AppleClang doesn't support all sanitizers, but leak gives error.
ASan/macOS: fix incomplete C/CXX compiler flags. 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
2020-09-16 02:16:15 +05:30
# Build type is not known for multi-config generator, so don't add object-size sanitizer.
if(CMAKE_BUILD_TYPE MATCHES "Debug" OR GENERATOR_IS_MULTI_CONFIG)
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
# Silence the warning that object-size is not effective in -O0.
set(_asan_defaults "${_asan_defaults}")
else()
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND _asan_defaults " -fsanitize=object-size")
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
endif()
Core: Fix ASAN on Clang-14 / Linux When using ASAN on Clang / Linux, the call to `find_library(... asan ...)` works against us, as it finds GCC's `libasan.so`. To work with Clang, we should simply not pass any explicit library, as Clang will figure things out by itself with the `-fsanitize=xxx` options. Furthermore, Clang is incompatible with `-fsanitize=object-size`, so that's now also no longer passed on Linux (mimicking the Apple) configuration. For the long run, it would be better to rewrite this entire section to select behaviour on a per-compiler basis, rather than per platform. That's tracked in #105956 Pull Request: https://projects.blender.org/blender/blender/pulls/106675
2023-04-11 14:15:34 +02:00
elseif(CMAKE_COMPILER_IS_GNUCC)
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND _asan_defaults " -fsanitize=leak -fsanitize=object-size")
Core: Fix ASAN on Clang-14 / Linux When using ASAN on Clang / Linux, the call to `find_library(... asan ...)` works against us, as it finds GCC's `libasan.so`. To work with Clang, we should simply not pass any explicit library, as Clang will figure things out by itself with the `-fsanitize=xxx` options. Furthermore, Clang is incompatible with `-fsanitize=object-size`, so that's now also no longer passed on Linux (mimicking the Apple) configuration. For the long run, it would be better to rewrite this entire section to select behaviour on a per-compiler basis, rather than per platform. That's tracked in #105956 Pull Request: https://projects.blender.org/blender/blender/pulls/106675
2023-04-11 14:15:34 +02:00
else()
string(APPEND _asan_defaults " -fsanitize=leak")
Add Asan support for clang on windows. This will currently only work for the RelWithDebInfo configuration since asan does not support the debug crt. for source line information in the reports, you need a copy of llvm-symbolizer in the blender folder or set the ASAN_SYMBOLIZER_PATH environment variable to point to it. Currently (as of 6.0.0) llvm-symbolizer does not ship with the binary clang/llvm distribution. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D3446
2018-05-31 11:50:30 -06:00
endif()
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
CMake: Add WITH_COMPILER_ASAN option This supports easy toggling of Address Sanitizer.
2018-05-18 15:21:18 +02:00
set(COMPILER_ASAN_CFLAGS "${_asan_defaults}" CACHE STRING "C flags for address sanitizer")
mark_as_advanced(COMPILER_ASAN_CFLAGS)
set(COMPILER_ASAN_CXXFLAGS "${_asan_defaults}" CACHE STRING "C++ flags for address sanitizer")
mark_as_advanced(COMPILER_ASAN_CXXFLAGS)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: Add WITH_COMPILER_ASAN option This supports easy toggling of Address Sanitizer.
2018-05-18 15:21:18 +02:00
unset(_asan_defaults)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
if(MSVC)
Cleanup: cmake indentation
2022-09-29 12:00:18 +10:00
find_library(
COMPILER_ASAN_LIBRARY NAMES clang_rt.asan-x86_64
Cleanup: trailing space in CMake files
2018-06-10 08:12:13 +02:00
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\LLVM\\LLVM;]/lib/clang/7.0.0/lib/windows
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\LLVM\\LLVM;]/lib/clang/6.0.0/lib/windows
)
Core: Fix ASAN on Clang-14 / Linux When using ASAN on Clang / Linux, the call to `find_library(... asan ...)` works against us, as it finds GCC's `libasan.so`. To work with Clang, we should simply not pass any explicit library, as Clang will figure things out by itself with the `-fsanitize=xxx` options. Furthermore, Clang is incompatible with `-fsanitize=object-size`, so that's now also no longer passed on Linux (mimicking the Apple) configuration. For the long run, it would be better to rewrite this entire section to select behaviour on a per-compiler basis, rather than per platform. That's tracked in #105956 Pull Request: https://projects.blender.org/blender/blender/pulls/106675
2023-04-11 14:15:34 +02:00
mark_as_advanced(COMPILER_ASAN_LIBRARY)
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
elseif(APPLE)
Cleanup: Fix whitespace changes Introduced in rB40dcf686f04f7db8110f9c85621eb8a0bd764080
2020-09-12 16:06:24 -06:00
execute_process(COMMAND ${CMAKE_CXX_COMPILER}
-print-file-name=lib
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
OUTPUT_VARIABLE CLANG_LIB_DIR
)
string(STRIP "${CLANG_LIB_DIR}" CLANG_LIB_DIR)
find_library(
ASan/macOS: fix incomplete C/CXX compiler flags. 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
2020-09-16 02:16:15 +05:30
COMPILER_ASAN_LIBRARY
NAMES
libclang_rt.asan_osx_dynamic.dylib
Cleanup: Fix whitespace changes Introduced in rB40dcf686f04f7db8110f9c85621eb8a0bd764080
2020-09-12 16:06:24 -06:00
PATHS
ASan/macOS: fix incomplete C/CXX compiler flags. 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
2020-09-16 02:16:15 +05:30
"${CLANG_LIB_DIR}/darwin/"
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
)
unset(CLANG_LIB_DIR)
Core: Fix ASAN on Clang-14 / Linux When using ASAN on Clang / Linux, the call to `find_library(... asan ...)` works against us, as it finds GCC's `libasan.so`. To work with Clang, we should simply not pass any explicit library, as Clang will figure things out by itself with the `-fsanitize=xxx` options. Furthermore, Clang is incompatible with `-fsanitize=object-size`, so that's now also no longer passed on Linux (mimicking the Apple) configuration. For the long run, it would be better to rewrite this entire section to select behaviour on a per-compiler basis, rather than per platform. That's tracked in #105956 Pull Request: https://projects.blender.org/blender/blender/pulls/106675
2023-04-11 14:15:34 +02:00
mark_as_advanced(COMPILER_ASAN_LIBRARY)
elseif(CMAKE_COMPILER_IS_GNUCC)
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
find_library(
COMPILER_ASAN_LIBRARY asan ${CMAKE_C_IMPLICIT_LINK_DIRECTORIES}
)
Core: Fix ASAN on Clang-14 / Linux When using ASAN on Clang / Linux, the call to `find_library(... asan ...)` works against us, as it finds GCC's `libasan.so`. To work with Clang, we should simply not pass any explicit library, as Clang will figure things out by itself with the `-fsanitize=xxx` options. Furthermore, Clang is incompatible with `-fsanitize=object-size`, so that's now also no longer passed on Linux (mimicking the Apple) configuration. For the long run, it would be better to rewrite this entire section to select behaviour on a per-compiler basis, rather than per platform. That's tracked in #105956 Pull Request: https://projects.blender.org/blender/blender/pulls/106675
2023-04-11 14:15:34 +02:00
mark_as_advanced(COMPILER_ASAN_LIBRARY)
Cleanup: trailing space in CMake files
2018-06-10 08:12:13 +02:00
endif()
Support ASan library on macOS for all generators. 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
2020-09-08 00:17:17 +05:30
CMake: Add WITH_COMPILER_ASAN option This supports easy toggling of Address Sanitizer.
2018-05-18 15:21:18 +02:00
endif()
endif()
Unbreak build on macOS with AppleClang from recent cleanup Exact an exact match with Clang broke building when the compiler ID was "AppleClang", reverting parts of [0]. [0]: 6549019ae19cecbea524782054dca0e99cb833b8
2024-03-07 19:56:58 +11:00
if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID MATCHES "Clang")
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_COMPILER_SHORT_FILE_MACRO "\
Make paths in macros like __FILE__ relative to top level source and build directories."
ON
)
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
mark_as_advanced(WITH_COMPILER_SHORT_FILE_MACRO)
endif()
CMake: confine WIN32 options
2017-03-06 04:05:00 +11:00
if(WIN32)
# Use hardcoded paths or find_package to find externals
option(WITH_WINDOWS_FIND_MODULES "Use find_package to locate libraries" OFF)
mark_as_advanced(WITH_WINDOWS_FIND_MODULES)
D2078 Windows : add option to prevent find_package from picking up the wrong libraries and use hardcoded paths instead.
2016-08-23 08:47:23 -06:00
Cleanup: cmake formatting, sort file lists
2025-02-10 19:38:51 +11:00
# The python debugger in Visual Studio for has been broken for years
# but the upstream project over at https://github.com/microsoft/PTVS
# show hopeful signs of life once in a while, so there is hope that
# at one point this will start working again. That being said people
# do keep turning this option on and end up disappointed it isn't
# working and they spend a whole bunch of time on trying to get it to
# work. So for now rather than removing this functionality
# completely, just disable it.
CMake: Disable WINDOWS_PYTHON_DEBUG The python debugger in Visual Studio for has been broken for years but the upstream project over at https://github.com/microsoft/PTVS show hopeful signs of life once in a while, so there is hope that at one point this will start working again. That being said people do keep turning this option on and end up disappointed it isn't working and they spend a whole bunch of time on trying to get it to work. So for now rather than removing this functionality completely, just disable it.
2025-01-23 08:36:30 -07:00
if(WINDOWS_PYTHON_DEBUG)
# No need for a python version check here, anything over python 3.6 isn't working.
message(WARNING "Unsupported python version for VS debugger, disabling WINDOWS_PYTHON_DEBUG")
set(WINDOWS_PYTHON_DEBUG OFF)
endif()
Cleanup: cmake formatting, sort file lists
2025-02-10 19:38:51 +11:00
# option(WINDOWS_PYTHON_DEBUG "\
# Include the files needed for debugging python scripts with visual studio 2017+."
# OFF
# )
# mark_as_advanced(WINDOWS_PYTHON_DEBUG)
Cleanup/Windows: Separate out the MS-CRT into a subfolder In older versions the ms crt was only a few dlls, in recent versions this jumped to over 40 leading to quite a bit of clutter in our bin folder. This change moves the CRT into its own folder. For developers that generally already have the runtime globaly available on their machine, there is a new cmake option (WITH_WINDOWS_BUNDLE_CRT, default ON) that you can use to toggle installing the runtime to the blender bin folder, and save some time during the initial build, this option is off by default for only the developer profile. Reviewed By: brecht Differential Revision: https://developer.blender.org/D6132
2019-12-06 10:12:03 -07:00
option(WITH_WINDOWS_BUNDLE_CRT "Bundle the C runtime for install free distribution." ON)
mark_as_advanced(WITH_WINDOWS_BUNDLE_CRT)
MSVC: Add cmake option for external manifests This PR adds a cmake option `WITH_WINDOWS_EXTERNAL_MANIFEST` which is off by default which addresses the following 2 problems: The CI env occasionally fails to link the manifest into blender.exe with mt.exe getting file in use error. The solutions mentioned online vary wildly between, just rebuild, turn off your AV, use this magic switch. None of them actually point to a root cause we can address. When building blender with clang and the visual studio generator it also somehow doesn't embed the manifest. If the bots stay problematic this option can be turned on for the CI environment, and will be automatically turned on when it detects clang and the visual studio generator being used. Pull Request: https://projects.blender.org/blender/blender/pulls/111683
2024-04-18 16:57:04 +02:00
option(WITH_WINDOWS_EXTERNAL_MANIFEST "Use external manifest files" OFF)
mark_as_advanced(WITH_WINDOWS_EXTERNAL_MANIFEST)
Windows: Add sccache support. sccache [1] is one of the few ccache like solutions that will work on windows. sccache support can be enabled with the `WITH_WINDOWS_SCCACHE` cmake option however it will only will work with ninja as the build system, msbuild is not supported currently. Advanced option, developes are expected to obtain and configure sccache on their own. ``` Full build no cache 1428.90s (100.00%) Full build cached 434.34s ( 30.40%) ``` [1] https://github.com/mozilla/sccache Reviewed By: nicholas_rishel, Brecht Differential Revision: https://developer.blender.org/D7466
2020-04-20 12:51:43 -06:00
option(WITH_WINDOWS_SCCACHE "Use sccache to speed up builds (Ninja builder only)" OFF)
mark_as_advanced(WITH_WINDOWS_SCCACHE)
Cleanup: CMake formatting
2023-10-07 19:46:38 +11:00
option(WITH_WINDOWS_RELEASE_PDB "\
Generate a pdb file for client side stacktraces for release builds"
ON
)
CMake/MSVC: Only generate/install stripped PDB for release builds This renames the WITH_WINDOWS_PDB and WITH_WINDOWS_STRIPPED_PDB cmake options to WITH_WINDOWS_RELEASE_PDB WITH_WINDOWS_RELEASE_STRIPPED_PDB The Stripped PDB isn't cost free to generate, and is only needed for builds that are distributed to end users. There is no benefit in making one for a debug build as the debugger locally will prefer to use the bigger un-stripped PDB anyhow. This also stops the copy/install of the PDB for anything but a release build, this file is about 1.6G for a debug build, and there is really no need to do this for local development, as the debugger will find/use the PDB from its original location. This brings down the time needed for an incremental link on a debug build by about 30% (10->7 seconds on my local system)
2023-08-18 10:20:36 -06:00
mark_as_advanced(WITH_WINDOWS_RELEASE_PDB)
Windows: Support backtraces on release builds. This diff add supports for crash logs on windows for release builds. This can be toggled on/off with the `WITH_WINDOWS_PDB` cmake option. by default it is on. Things to take into consideration: Release builds are hightly optimized and the resulting backtraces can be wrong/misleading, take the backtrace as a general area where the problem resides rather than an exact location. By default we ship a minimized symbol file that can only resolve the function names. This was chosen to strike a balance between growth in size of the download vs functionality gained. If more detailed information is required such as source file + line number information a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB` to off. Differential Revision: https://developer.blender.org/D7520 Reviewed by: brecht
2020-05-01 07:37:48 -06:00
CMake/MSVC: Only generate/install stripped PDB for release builds This renames the WITH_WINDOWS_PDB and WITH_WINDOWS_STRIPPED_PDB cmake options to WITH_WINDOWS_RELEASE_PDB WITH_WINDOWS_RELEASE_STRIPPED_PDB The Stripped PDB isn't cost free to generate, and is only needed for builds that are distributed to end users. There is no benefit in making one for a debug build as the debugger locally will prefer to use the bigger un-stripped PDB anyhow. This also stops the copy/install of the PDB for anything but a release build, this file is about 1.6G for a debug build, and there is really no need to do this for local development, as the debugger will find/use the PDB from its original location. This brings down the time needed for an incremental link on a debug build by about 30% (10->7 seconds on my local system)
2023-08-18 10:20:36 -06:00
option(WITH_WINDOWS_RELEASE_STRIPPED_PDB "Use a stripped PDB file for release builds" ON)
mark_as_advanced(WITH_WINDOWS_RELEASE_STRIPPED_PDB)
Windows: Support backtraces on release builds. This diff add supports for crash logs on windows for release builds. This can be toggled on/off with the `WITH_WINDOWS_PDB` cmake option. by default it is on. Things to take into consideration: Release builds are hightly optimized and the resulting backtraces can be wrong/misleading, take the backtrace as a general area where the problem resides rather than an exact location. By default we ship a minimized symbol file that can only resolve the function names. This was chosen to strike a balance between growth in size of the download vs functionality gained. If more detailed information is required such as source file + line number information a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB` to off. Differential Revision: https://developer.blender.org/D7520 Reviewed by: brecht
2020-05-01 07:37:48 -06:00
CMake: confine WIN32 options
2017-03-06 04:05:00 +11:00
endif()
[Windows] Add support for code signing the final binaries. The option is controlled with the WITH_WINDOWS_CODESIGN option and needs: - Signtool must be found on the system, the standard windows sdk folders will be searched for it. - The path to the pfx file (WINDOWS_CODESIGN_PFX) - The password for the pfx , this can either be set by the WINDOWS_CODESIGN_PFX_PASSWORD variable but given that ends up in CMakeCache.txt (which might be undesirable) there is a backup option of setting the PFXPASSWORD environment variable on the system. Reviewers: sergey, juicyfruit Reviewed By: juicyfruit Tags: #bf_blender, #platform:_windows Differential Revision: https://developer.blender.org/D2182
2016-08-31 06:26:05 -06:00
Xcode: support cmake options for grouping in folders The Xcode IDE can also benefit from the options: - WINDOWS_USE_VISUAL_STUDIO_SOURCE_FOLDERS - WINDOWS_USE_VISUAL_STUDIO_PROJECT_FOLDERS So add suport to these options and also renames them as they are no longer limited to just Windows and Visual Studio. Reviewed By: brecht, ankitm Differential Revision: https://developer.blender.org/D12132
2021-08-05 12:49:55 -03:00
if(WIN32 OR XCODE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(IDE_GROUP_SOURCES_IN_FOLDERS "\
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
Organize the source files in filters matching the source directory."
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
ON
)
Xcode: support cmake options for grouping in folders The Xcode IDE can also benefit from the options: - WINDOWS_USE_VISUAL_STUDIO_SOURCE_FOLDERS - WINDOWS_USE_VISUAL_STUDIO_PROJECT_FOLDERS So add suport to these options and also renames them as they are no longer limited to just Windows and Visual Studio. Reviewed By: brecht, ankitm Differential Revision: https://developer.blender.org/D12132
2021-08-05 12:49:55 -03:00
mark_as_advanced(IDE_GROUP_SOURCES_IN_FOLDERS)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(IDE_GROUP_PROJECTS_IN_FOLDERS "\
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
Organize the projects according to source directory structure."
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
ON
)
Xcode: support cmake options for grouping in folders The Xcode IDE can also benefit from the options: - WINDOWS_USE_VISUAL_STUDIO_SOURCE_FOLDERS - WINDOWS_USE_VISUAL_STUDIO_PROJECT_FOLDERS So add suport to these options and also renames them as they are no longer limited to just Windows and Visual Studio. Reviewed By: brecht, ankitm Differential Revision: https://developer.blender.org/D12132
2021-08-05 12:49:55 -03:00
mark_as_advanced(IDE_GROUP_PROJECTS_IN_FOLDERS)
Cleanup: indentation for CMake files Also minor white-space & case changes.
2022-01-28 14:08:11 +11:00
if(IDE_GROUP_PROJECTS_IN_FOLDERS)
Xcode: support cmake options for grouping in folders The Xcode IDE can also benefit from the options: - WINDOWS_USE_VISUAL_STUDIO_SOURCE_FOLDERS - WINDOWS_USE_VISUAL_STUDIO_PROJECT_FOLDERS So add suport to these options and also renames them as they are no longer limited to just Windows and Visual Studio. Reviewed By: brecht, ankitm Differential Revision: https://developer.blender.org/D12132
2021-08-05 12:49:55 -03:00
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
endif()
endif()
Unix/macOS: support building with Ccache This adds an option (WITH_COMPILER_CCACHE) to build using Ccache if it's found. Makefiles-based, Ninja-based and Xcode generators are supported. Pass `-DWITH_COMPILER_CCACHE=ON` to cmake to enable Ccache. Utility option in GNUmakefile is also added: for e.g., `make ninja ccache`. Reviewed By: brecht, ankitm Differential Revision: https://developer.blender.org/D9665
2020-12-21 10:47:35 +05:30
if(UNIX)
# See WITH_WINDOWS_SCCACHE for Windows.
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_COMPILER_CCACHE "\
Use ccache to improve rebuild times (Works with Ninja, Makefiles and Xcode)"
OFF
)
CMake: set compiler-ccache & build-type-init variables as advanced These settings aren't useful for basic configuration.
2021-02-10 17:42:31 +11:00
mark_as_advanced(WITH_COMPILER_CCACHE)
Unix/macOS: support building with Ccache This adds an option (WITH_COMPILER_CCACHE) to build using Ccache if it's found. Makefiles-based, Ninja-based and Xcode generators are supported. Pass `-DWITH_COMPILER_CCACHE=ON` to cmake to enable Ccache. Utility option in GNUmakefile is also added: for e.g., `make ninja ccache`. Reviewed By: brecht, ankitm Differential Revision: https://developer.blender.org/D9665
2020-12-21 10:47:35 +05:30
endif()
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
# The following only works with the Ninja generator in CMake >= 3.0.
if("${CMAKE_GENERATOR}" MATCHES "Ninja")
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_NINJA_POOL_JOBS "\
Enable Ninja pools of jobs, to try to ease building on machines with 16GB of RAM or less \
(if not yet defined, will try to set best values based on detected machine specifications)."
Build: Ninja: Enable pooljobs by default. Using pooljobs with default settings should never have any significant impact on the build speed, and it makes building full debug with sanitizer builds safe on (almost) all machines. Quick test showed no significant difference in Release build time with or without Ninja pooljobs (on linux, with a 16 cores, 64GBb machine).
2024-01-04 16:47:03 +01:00
ON
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
mark_as_advanced(WITH_NINJA_POOL_JOBS)
endif()
Initial implementation of code signing routines This changes integrates code signing steps into a buildbot worker process. The configuration requires having a separate machine running with a shared folder access between the signing machine and worker machine. Actual signing is happening as a "POST-INSTALL" script run by CMake, which allows to sign any binary which ends up in the final bundle. Additionally, such way allows to avoid signing binaries in the build folder (if we were signing as a built process, which iwas another alternative). Such complexity is needed on platforms which are using CPack to generate final bundle: CPack runs INSTALL target into its own location, so it is useless to run signing on a folder which is considered INSTALL by the buildbot worker. There is a signing script which can be used as a standalone tool, making it possible to hook up signing for macOS's bundler. There is a dummy Linux signer implementation, which can be activated by returning True from mock_codesign in linux_code_signer.py. Main purpose of this signer is to give an ability to develop the scripts on Linux environment, without going to Windows VM. The code is based on D6036 from Nathan Letwory. Differential Revision: https://developer.blender.org/D6216
2019-11-07 16:50:31 +01:00
# Installation process.
CMake Cleanup: use set for filepath instead of option See https://developer.blender.org/D13830#368219
2022-01-19 23:34:25 +05:30
set(POSTINSTALL_SCRIPT "" CACHE FILEPATH "Run given CMake script after installation process")
Initial implementation of code signing routines This changes integrates code signing steps into a buildbot worker process. The configuration requires having a separate machine running with a shared folder access between the signing machine and worker machine. Actual signing is happening as a "POST-INSTALL" script run by CMake, which allows to sign any binary which ends up in the final bundle. Additionally, such way allows to avoid signing binaries in the build folder (if we were signing as a built process, which iwas another alternative). Such complexity is needed on platforms which are using CPack to generate final bundle: CPack runs INSTALL target into its own location, so it is useless to run signing on a folder which is considered INSTALL by the buildbot worker. There is a signing script which can be used as a standalone tool, making it possible to hook up signing for macOS's bundler. There is a dummy Linux signer implementation, which can be activated by returning True from mock_codesign in linux_code_signer.py. Main purpose of this signer is to give an ability to develop the scripts on Linux environment, without going to Windows VM. The code is based on D6036 from Nathan Letwory. Differential Revision: https://developer.blender.org/D6216
2019-11-07 16:50:31 +01:00
mark_as_advanced(POSTINSTALL_SCRIPT)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(POSTCONFIGURE_SCRIPT "" CACHE FILEPATH "\
Run given CMake script as the last step of CMake configuration"
)
CMake: Support external callback in configuration An external CMake script can be used to debug CMake code, modify/read target properties, inter-target dependencies, non-cache variables etc. Reviewed by: LazyDodo, brecht Differential Revision: https://developer.blender.org/D13830
2022-01-20 00:15:09 +05:30
mark_as_advanced(POSTCONFIGURE_SCRIPT)
CMake: disable some build option defaults T42569 This commit disables some lesser used dependencies for Linux/Unix systems by default. Run: `make full` to enabled options used in release build.
2014-11-13 23:32:01 +01:00
# end option(...)
Fix: T42553 Linux cmake install now also without absolute path's OS X cmake probably needs more checking.
2014-11-11 21:44:26 +01:00
cmake buildfiles Cleanup / Refactor, no functional changes. Move away from using hardcoded ${target} when calling install() in cmake
2014-11-08 11:32:32 +01:00
# By default we want to install to the directory we are compiling our executables
# unless specified otherwise, which we currently do not allow
Cleanup: cmake
2014-11-13 15:03:30 +01:00
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
CMake: make install prefix option irrelevant for MinGW too.
2015-12-27 16:57:31 +01:00
if(WIN32)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(CMAKE_INSTALL_PREFIX ${EXECUTABLE_OUTPUT_PATH}/\${BUILD_TYPE} CACHE PATH "\
default install path"
FORCE
)
Only do the portable fix on linux - thanks to Martijn Berger for noticing!
2014-11-13 14:10:30 +01:00
elseif(APPLE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(CMAKE_INSTALL_PREFIX ${EXECUTABLE_OUTPUT_PATH}/\${BUILD_TYPE} CACHE PATH "\
default install path"
FORCE
)
Only do the portable fix on linux - thanks to Martijn Berger for noticing!
2014-11-13 14:10:30 +01:00
else()
Cleanup: cmake
2014-11-13 15:03:30 +01:00
if(WITH_INSTALL_PORTABLE)
set(CMAKE_INSTALL_PREFIX ${EXECUTABLE_OUTPUT_PATH} CACHE PATH "default install path" FORCE)
Only do the portable fix on linux - thanks to Martijn Berger for noticing!
2014-11-13 14:10:30 +01:00
endif()
endif()
cmake buildfiles Cleanup / Refactor, no functional changes. Move away from using hardcoded ${target} when calling install() in cmake
2014-11-08 11:32:32 +01:00
endif()
Fix: T42553 Linux cmake install now also without absolute path's OS X cmake probably needs more checking.
2014-11-11 21:44:26 +01:00
Cleanup: replace the term "folder" with "directory" for CMake files This was already more common an in keeping with cmake's own naming.
2024-09-14 12:35:02 +10:00
# Effective install path including config directory, as a generator expression.
Build: add system for shipping with dynamic libraries on Linux and macOS PLATFORM_BUNDLED_LIBRARIES gathers shared libraries that will be installed to the lib/ folder. The Blender executable gets a relative rpath pointing to this folder as part of the install step. The build rpath is different and uses absolute paths, so that it works for executables like tests that are in different locations, and to support the case where the build and install folders are different. The system is already used for the OpenMP library on macOS. But on Linux it will only kick in once we start using shared libraries for dependencies. This also removes Mesa libraries from the old location, as these would cause Blender to start with software OpenGL. Ref T99618
2022-08-18 17:07:10 +02:00
get_property(GENERATOR_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(GENERATOR_IS_MULTI_CONFIG)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
string(
REPLACE "\${BUILD_TYPE}" "$<CONFIG>"
CMAKE_INSTALL_PREFIX_WITH_CONFIG ${CMAKE_INSTALL_PREFIX}
)
Build: add system for shipping with dynamic libraries on Linux and macOS PLATFORM_BUNDLED_LIBRARIES gathers shared libraries that will be installed to the lib/ folder. The Blender executable gets a relative rpath pointing to this folder as part of the install step. The build rpath is different and uses absolute paths, so that it works for executables like tests that are in different locations, and to support the case where the build and install folders are different. The system is already used for the OpenMP library on macOS. But on Linux it will only kick in once we start using shared libraries for dependencies. This also removes Mesa libraries from the old location, as these would cause Blender to start with software OpenGL. Ref T99618
2022-08-18 17:07:10 +02:00
else()
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
string(
REPLACE "\${BUILD_TYPE}" ""
CMAKE_INSTALL_PREFIX_WITH_CONFIG ${CMAKE_INSTALL_PREFIX}
)
Build: add system for shipping with dynamic libraries on Linux and macOS PLATFORM_BUNDLED_LIBRARIES gathers shared libraries that will be installed to the lib/ folder. The Blender executable gets a relative rpath pointing to this folder as part of the install step. The build rpath is different and uses absolute paths, so that it works for executables like tests that are in different locations, and to support the case where the build and install folders are different. The system is already used for the OpenMP library on macOS. But on Linux it will only kick in once we start using shared libraries for dependencies. This also removes Mesa libraries from the old location, as these would cause Blender to start with software OpenGL. Ref T99618
2022-08-18 17:07:10 +02:00
endif()
cmake buildfiles Cleanup / Refactor, no functional changes. Move away from using hardcoded ${target} when calling install() in cmake
2014-11-08 11:32:32 +01:00
Ghost Context Refactor https://developer.blender.org/D643 Separates graphics context creation from window code in Ghost so that they can vary separately.
2014-10-07 15:46:19 -05:00
# Apple
Detect SSE building support with cmake, and moved setting the defines out of the render mode cmake file into the main one. Should fix PPC compile, and hopefully not break others.
2010-07-04 18:40:59 +00:00
if(APPLE)
CMake: move some Apple specific code into platform_apple_xcode.cmake.
2017-04-23 17:42:45 +02:00
include(platform_apple_xcode)
CMake: - WITH_LCMS added option, was supported in scons. - commented web plugin option since its not maintained. - some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
2010-06-06 13:32:58 +00:00
Cleanup: CMake: Merge `APPLE` blocks, wrap long option description line
2025-04-27 23:23:49 +02:00
option(WITH_LEGACY_MACOS_X64_LINKER "\
Use legacy macOS linker on x64 platform. Minutes slower, but emits fewer warnings."
OFF
)
macOS: Default to modern linker on x64 This patch changes the default macOS x64 linker from the slower legacy "classic" linker, to the much faster default modern macOS linker. A new CMake option `WITH_LEGACY_MACOS_X64_LINKER` was also introduced to use the old linker, set to OFF by default. As an example from testing on an Intel Macbook, this makes linking time go from 3min25s to 10s after this change. The reason why the legacy linker was enforced on x64 in the first place was to silence "platform load command not found" warnings during linking. Since this behavior is still desired on the BuildBot, the `WITH_LEGACY_MACOS_X64_LINKER` option is enforced in the BuildBot macOS configs. Pull Request: https://projects.blender.org/blender/blender/pulls/134639
2025-04-21 10:56:36 +02:00
mark_as_advanced(WITH_LEGACY_MACOS_X64_LINKER)
endif()
print warning when release/datafiles/locale is missing when building with cmake (git-svn causes this).
2012-03-13 22:27:21 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Check for Conflicting/Unsupported Configurations
don't write file history in backgound mode (running ctest would overwrite all my recent-files.txt), and add an error about mingw/quicktime being unsupported.
2011-06-08 01:53:12 +00:00
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
option(WITH_STRICT_BUILD_OPTIONS "\
When requirements for a build option are not met, error instead of disabling the option."
OFF
)
Build: add option to error when features can't be enabled This is to help ensure buildbot builds are correct, while still gracefully disabling features in user/developer builds. * Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be enabled due to missing libraries or other reasons. Add new macro set_and_warn_library_found used everywhere features were being automatically disabled. * Remove code from Windows and macOS for various libraries that would automatically disable features. set_and_warn_library_found could be used here also, but we are generally assuming the precompiled libraries are complete and only test for availability when libraries are just added. Differential Revision: https://developer.blender.org/D16104
2022-09-29 19:01:35 +02:00
Cycles: Add Hydra render delegate This patch adds a Hydra render delegate to Cycles, allowing Cycles to be used for rendering in applications that provide a Hydra viewport. The implementation was written from scratch against Cycles X, for integration into the Blender repository to make it possible to continue developing it in step with the rest of Cycles. For this purpose it follows the style of the rest of the Cycles code and can be built with a CMake option (`WITH_CYCLES_HYDRA_RENDER_DELEGATE=1`) similar to the existing standalone version of Cycles. Since Hydra render delegates need to be built against the exact USD version and other dependencies as the target application is using, this is intended to be built separate from Blender (`WITH_BLENDER=0` CMake option) and with support for library versions different from what Blender is using. As such the CMake build scripts for Windows had to be modified slightly, so that the Cycles Hydra render delegate can e.g. be built with MSVC 2017 again even though Blender requires MSVC 2019 now, and it's possible to specify custom paths to the USD SDK etc. The codebase supports building against the latest USD release 22.03 and all the way back to USD 20.08 (with some limitations). Reviewed By: brecht, LazyDodo Differential Revision: https://developer.blender.org/D14398
2022-03-23 16:07:43 +01:00
if(NOT WITH_BLENDER AND NOT WITH_CYCLES_STANDALONE AND NOT WITH_CYCLES_HYDRA_RENDER_DELEGATE)
Cleanup: cmake, indentation, line length
2016-05-18 11:58:08 +10:00
message(FATAL_ERROR
Disable GAME ENGINE from the build options
2018-04-16 15:54:36 +02:00
"At least one of WITH_BLENDER or WITH_CYCLES_STANDALONE "
Cycles: Add Hydra render delegate This patch adds a Hydra render delegate to Cycles, allowing Cycles to be used for rendering in applications that provide a Hydra viewport. The implementation was written from scratch against Cycles X, for integration into the Blender repository to make it possible to continue developing it in step with the rest of Cycles. For this purpose it follows the style of the rest of the Cycles code and can be built with a CMake option (`WITH_CYCLES_HYDRA_RENDER_DELEGATE=1`) similar to the existing standalone version of Cycles. Since Hydra render delegates need to be built against the exact USD version and other dependencies as the target application is using, this is intended to be built separate from Blender (`WITH_BLENDER=0` CMake option) and with support for library versions different from what Blender is using. As such the CMake build scripts for Windows had to be modified slightly, so that the Cycles Hydra render delegate can e.g. be built with MSVC 2017 again even though Blender requires MSVC 2019 now, and it's possible to specify custom paths to the USD SDK etc. The codebase supports building against the latest USD release 22.03 and all the way back to USD 20.08 (with some limitations). Reviewed By: brecht, LazyDodo Differential Revision: https://developer.blender.org/D14398
2022-03-23 16:07:43 +01:00
"or WITH_CYCLES_HYDRA_RENDER_DELEGATE "
Disable GAME ENGINE from the build options
2018-04-16 15:54:36 +02:00
"must be enabled, nothing to do!"
Cleanup: cmake, indentation, line length
2016-05-18 11:58:08 +10:00
)
Advanced CMake option to build the player without blender: WITH_BLENDER
2011-07-13 08:15:06 +00:00
endif()
Audaspace: porting minor improvements from upstream - NullDevice is now called None - Automatic choice of best available device. - Minor formatting, documentation and cmake fixes.
2021-03-16 22:32:16 +01:00
set_and_warn_dependency(WITH_AUDASPACE WITH_OPENAL OFF)
Audaspace: add support for CoreAudio on macOS This adds CoreAudio as audio backend on macOS. CoreAudio is the standard audio API on macOS. Ref T86590
2021-03-14 12:46:47 +01:00
set_and_warn_dependency(WITH_AUDASPACE WITH_COREAUDIO OFF)
Audaspace: porting minor improvements from upstream - NullDevice is now called None - Automatic choice of best available device. - Minor formatting, documentation and cmake fixes.
2021-03-16 22:32:16 +01:00
set_and_warn_dependency(WITH_AUDASPACE WITH_JACK OFF)
Audaspace: add support for PulseAudio on Linux This adds PulseAudio as audio backend on Linux. PulseAudio is the main audio engine used on most, if not all, Linux distributions today. Ref T86590
2021-03-02 17:29:18 +01:00
set_and_warn_dependency(WITH_AUDASPACE WITH_PULSEAUDIO OFF)
Audaspace: add support for WASAPI on Windows This adds WASAPI as audio backend on Windows. WASAPI is the modern standard audio API on Windows introduced with Windows Vista. Ref T86590
2021-03-11 19:22:56 +01:00
set_and_warn_dependency(WITH_AUDASPACE WITH_WASAPI OFF)
cmake option to build without an audio library.
2011-06-23 09:27:56 +00:00
- don't build ghost's event printer unless ghost debug is enabled. - use char rather then STR_String for the event printer. - added option to build WITH_GHOST_DEBUG for cmake - renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
2011-07-13 06:04:54 +00:00
if(NOT WITH_SDL AND WITH_GHOST_SDL)
replace BM_edge_face_count with BM_edge_is_manifold/BM_edge_is_wire/BM_edge_is_boundary
2012-11-12 04:50:45 +00:00
message(FATAL_ERROR "WITH_GHOST_SDL requires WITH_SDL")
build option to use SDL 1.3 for GHOST rather then X11/Win32/Cocoa api's, This opens up the option for blender to be more easily ported to other devices, OS's. TODO - continuous grab. - text glitch with multiple windows (was a bug in X11 too for a while, will check on this)
2011-07-12 13:17:54 +00:00
endif()
Removing Blender Game Engine from Blender 2.8 Folders removed entirely: * //extern/recastnavigation * //intern/decklink * //intern/moto * //source/blender/editors/space_logic * //source/blenderplayer * //source/gameengine This includes DNA data and any reference to the BGE code in Blender itself. We are bumping the subversion. Pending tasks: * Tile/clamp code in image editor draw code. * Viewport drawing code (so much of this will go away because of BI removal that we can wait until then to remove this.
2018-04-16 14:07:42 +02:00
# python module, needs some different options
disable some conflicting options WITH_PYTHON_MODULE
2011-02-22 14:27:46 +00:00
if(WITH_PYTHON_MODULE AND WITH_PYTHON_INSTALL)
message(FATAL_ERROR "WITH_PYTHON_MODULE requires WITH_PYTHON_INSTALL to be OFF")
endif()
CMake: issue warnings when changing options Only done in top level CMakeLists, and platform_apple. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D10343
2021-03-30 20:28:45 +05:30
set_and_warn_dependency(WITH_PYTHON WITH_CYCLES OFF)
set_and_warn_dependency(WITH_PYTHON WITH_DRACO OFF)
CMake: disable WITH_MOD_FLUID when WITH_PYTHON=OFF
2022-05-20 11:17:32 +10:00
set_and_warn_dependency(WITH_PYTHON WITH_MOD_FLUID OFF)
disable cycles when building without python, also use const for function args in more places.
2013-08-07 22:40:03 +00:00
Booleans: Boost is no longer a dependency for Carve SCons is currently broken on my laptop, so can't test if it works for sure, so please do tests of that.
2014-11-13 17:36:33 +05:00
# enable boost for cycles, audaspace or i18n
expose WITH_BOOST as a cmake option, this just disables boost deps since it was becoming annoying to remember all of them.
2013-01-31 23:25:06 +00:00
# otherwise if the user disabled
BuildSystem/Cleanup: Fix warning behaviour regarding library dependencies Adding USD to a lite build fails to build due to boost errors, when you turn boost on and rebuild still boost errors, boost was silently turned off since it was not deemed needed. Once boost was forced on, it still fails due to TBB being off. This patch fixes: - The Silent disabling of boost - Add a check that USD is is not on before doing that - move the TBB checks to a central location rather than the individual platform files - Add USD to the TBB checks. Differential Revision: https://developer.blender.org/D6479 Reviewers: brecht, sybren
2020-02-07 07:27:40 -07:00
set_and_warn_dependency(WITH_BOOST WITH_OPENVDB OFF)
set_and_warn_dependency(WITH_BOOST WITH_USD OFF)
CMake: Fix noisy PUGIXML warning. When doing a lite build, a warning is displayed that due to PUGIXML being off WITH_CYCLES_OSL is being disabled as well. If WITH_CYCLES is off this is just useless noise. this diff changes the warning to only emit when WITH_CYCLES is on.
2022-05-10 16:38:20 -06:00
if(WITH_CYCLES)
Fix: Cycles lite build failure without Pugixml
2024-12-26 23:03:39 +01:00
set_and_warn_dependency(WITH_BOOST WITH_CYCLES_OSL OFF)
set_and_warn_dependency(WITH_PUGIXML WITH_CYCLES_OSL OFF)
set_and_warn_dependency(WITH_PUGIXML WITH_CYCLES_STANDALONE OFF)
set_and_warn_dependency(WITH_CYCLES_OSL WITH_CYCLES_TEST_OSL OFF)
CMake: Fix noisy PUGIXML warning. When doing a lite build, a warning is displayed that due to PUGIXML being off WITH_CYCLES_OSL is being disabled as well. If WITH_CYCLES is off this is just useless noise. this diff changes the warning to only emit when WITH_CYCLES is on.
2022-05-10 16:38:20 -06:00
endif()
BuildSystem/Cleanup: Fix warning behaviour regarding library dependencies Adding USD to a lite build fails to build due to boost errors, when you turn boost on and rebuild still boost errors, boost was silently turned off since it was not deemed needed. Once boost was forced on, it still fails due to TBB being off. This patch fixes: - The Silent disabling of boost - Add a check that USD is is not on before doing that - move the TBB checks to a central location rather than the individual platform files - Add USD to the TBB checks. Differential Revision: https://developer.blender.org/D6479 Reviewers: brecht, sybren
2020-02-07 07:27:40 -07:00
Cycles: make TBB a required library dependency, and use in a few places Now that the rest of Blender also relies on TBB, no point in maintaining custom code for paraller_for and thread local storage.
2020-06-05 12:53:38 +02:00
set_and_warn_dependency(WITH_TBB WITH_CYCLES OFF)
BuildSystem/Cleanup: Fix warning behaviour regarding library dependencies Adding USD to a lite build fails to build due to boost errors, when you turn boost on and rebuild still boost errors, boost was silently turned off since it was not deemed needed. Once boost was forced on, it still fails due to TBB being off. This patch fixes: - The Silent disabling of boost - Add a check that USD is is not on before doing that - move the TBB checks to a central location rather than the individual platform files - Add USD to the TBB checks. Differential Revision: https://developer.blender.org/D6479 Reviewers: brecht, sybren
2020-02-07 07:27:40 -07:00
set_and_warn_dependency(WITH_TBB WITH_USD OFF)
set_and_warn_dependency(WITH_TBB WITH_OPENVDB OFF)
set_and_warn_dependency(WITH_TBB WITH_MOD_FLUID OFF)
Cycles: Add NanoVDB support for rendering volumes 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
2020-10-02 17:40:28 +02:00
# NanoVDB requires OpenVDB to convert the data structure
set_and_warn_dependency(WITH_OPENVDB WITH_NANOVDB OFF)
BuildSystem/Cleanup: Fix warning behaviour regarding library dependencies Adding USD to a lite build fails to build due to boost errors, when you turn boost on and rebuild still boost errors, boost was silently turned off since it was not deemed needed. Once boost was forced on, it still fails due to TBB being off. This patch fixes: - The Silent disabling of boost - Add a check that USD is is not on before doing that - move the TBB checks to a central location rather than the individual platform files - Add USD to the TBB checks. Differential Revision: https://developer.blender.org/D6479 Reviewers: brecht, sybren
2020-02-07 07:27:40 -07:00
Vulkan: Low Precision Float Conversion This PR adds conversion template to convert between Low Precision float formats. These include Binary32 floats and lower. It also adds support to convert between unsigned and signed float formats and float formats with different mantissa and exponents. Additionally overflows (values that don't fit in the target float format) will be clamped to the maximum value. **Reasoning**: Up to now the Vulkan backend only supported float and half float formats, but to support workbench, 11 and 10 unsigned floats have to be supported as well. The available libraries that support those float formats targets scientific applications. Where the final code couldn't be optimized that well by the compiler. Data conversion for color pixels have different requirements about clamping and sign, what could eliminate some clamping code in other areas in Blender as well. Also could fix some undesired overflow when using pixels with high intensity that didn't fit in the texture format leading to known artifects in Eevee and slow-down in the image editor. **Future** In the future we might want to move this to the public part of the GPU module so we can use this as well in other areas (Metal backend), Imbuf clamping See 3c658d2c2e69e9cf97dfaa7a3c164262aefb9e76 for a commit that uses this and improves image editor massively as it doesn't need to reiterate over the image buffer to clamp the values into a known range. Pull Request: https://projects.blender.org/blender/blender/pulls/108168
2023-06-07 07:50:04 +02:00
# OpenVDB, Alembic and OSL uses 'half' or 'imath' from OpenEXR
CMake: make OpenVDB depend on OpenEXR OpenVDB uses 'half' type & fails to link without it.
2020-03-04 10:39:53 +11:00
set_and_warn_dependency(WITH_IMAGE_OPENEXR WITH_OPENVDB OFF)
CMake: Disable Options Depending on OpenEXR Dependecies OpenEXR has some dependecies that other other modules in Blender requires. When disabling OpenEXR these dependecies could not match and building blender would fail. This PR disables the next options when `WITH_IMAGE_OPENEXR=Off` - `WITH_OPENVDB` - `WITH_ALEMBIC` - `WITH_VULKAN_BACKEND` - `WITH_CYCLES_OSL` Additionally windows stores the IMath libraries in `IMATH_LIBRARIES` Linux and Mac stored the IMath libraries in `IMATH_LIBRARY`. This change will also adds `IMATH_LIBRARIES` variable to all platforms. Pull Request: https://projects.blender.org/blender/blender/pulls/106209
2023-04-03 09:50:50 +02:00
set_and_warn_dependency(WITH_IMAGE_OPENEXR WITH_ALEMBIC OFF)
set_and_warn_dependency(WITH_IMAGE_OPENEXR WITH_CYCLES_OSL OFF)
CMake: make OpenVDB depend on OpenEXR OpenVDB uses 'half' type & fails to link without it.
2020-03-04 10:39:53 +11:00
Render: support USD Hydra render delegates Hydra is a rendering architecture part of USD, designed to abstract the host application from the renderer. A renderer implementing a Hydra render delegate can run in any host application supporting Hydra, which now includes Blender. For external renderers this means less code to be written, and improved performance due to a using a C++ API instead of a Python API. Add-ons need to subclass bpy.types.HydraRenderEngine. See the example in the Python API docs for details. An add-on for Hydra Storm will be included as well. This is USD's rasterizing renderer, used in other applications like usdview. For users it can provide a preview of USD file export, and for developers it serves a reference. There are still limitations and missing features, especially around materials. The remaining to do items are tracked in #110765. This feature was contributed by AMD. Ref #110765 Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com> Co-authored-by: Vasyl-Pidhirskyi <vpidhirskyi@gmail.com> Co-authored-by: Brian Savery <brian.savery@gmail.com> Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/104712
2023-08-04 15:10:48 +02:00
# Hydra requires USD.
set_and_warn_dependency(WITH_USD WITH_HYDRA OFF)
Build: Disable WITH_MOD_OCEANSIM when WITH_FFTW3 is disabled Bring behavior in line with other options. Pull Request: https://projects.blender.org/blender/blender/pulls/122865
2024-06-12 16:36:50 +02:00
# The Ocean modifier requires FFTW3.
set_and_warn_dependency(WITH_FFTW3 WITH_MOD_OCEANSIM OFF)
Build: Remove LLVM linking no longer needed by OSL These are now included in the OSL shared libraries, so no reason to link against it. The CMake code for WITH_LLVM remains in case it is useful in the future, but is not enabled by any Blender feature now. Pull Request: https://projects.blender.org/blender/blender/pulls/118229
2024-02-14 12:06:52 +01:00
if(NOT WITH_CYCLES)
CMake: disable OSL if cycles is disabled
2015-06-14 09:50:33 +10:00
set(WITH_CYCLES_OSL OFF)
CMake fix: OpenEXR and Tiff are linking dependencies of OIIO, and fix for Boost-Cycles-OIIO order The NOT BOOST test was changing Cycles so should be before the cycles-oiio link (by Campbell Barton, thanks) And exr and tiff are required for oiio (on OSX at least)
2013-03-27 18:44:46 +00:00
endif()
code cleanup: correct spelling
2012-09-28 06:45:20 +00:00
# don't store paths to libs for portable distribution
cmake: skip rpath (paths to libs) for portable distrobution
2011-08-23 20:19:08 +00:00
if(WITH_INSTALL_PORTABLE)
set(CMAKE_SKIP_BUILD_RPATH TRUE)
endif()
CMake: fix building on macOS
2023-10-07 20:21:52 +11:00
if(UNIX AND NOT (APPLE OR HAIKU))
set_and_warn_incompatible(WITH_HEADLESS WITH_GHOST_WAYLAND OFF)
set_and_warn_incompatible(WITH_HEADLESS WITH_GHOST_X11 OFF)
endif()
CMake: add set_and_warn_incompatible macro, use for HEADLESS & GHOST_SDL When WITH_GHOST_SDL or WITH_HEADLESS were used, the message didn't make much sense, especially since the features warned about weren't necessarily enabled or even supported by the platform. Replace with a `set_and_warn_incompatible` macro which only reports configuration changes based on incompatible features.
2023-10-07 19:11:51 +11:00
set_and_warn_incompatible(WITH_HEADLESS WITH_GHOST_SDL OFF)
Cleanup: set WITH_INPUT_IME=OFF when unsupported This avoids having to do platform checks before checking WITH_INPUT_IME.
2023-10-18 22:04:25 +11:00
if(WITH_INPUT_IME)
CMake: set_and_warn_incompatible now warns if arguments are undefined Previously this caused an error which can happen on other platforms that don't define the features being checked.
2023-10-07 21:22:13 +11:00
set_and_warn_incompatible(WITH_HEADLESS WITH_INPUT_IME OFF)
set_and_warn_incompatible(WITH_GHOST_SDL WITH_INPUT_IME OFF)
endif()
set_and_warn_incompatible(WITH_HEADLESS WITH_XR_OPENXR OFF)
CMake: add set_and_warn_incompatible macro, use for HEADLESS & GHOST_SDL When WITH_GHOST_SDL or WITH_HEADLESS were used, the message didn't make much sense, especially since the features warned about weren't necessarily enabled or even supported by the platform. Replace with a `set_and_warn_incompatible` macro which only reports configuration changes based on incompatible features.
2023-10-07 19:11:51 +11:00
set_and_warn_incompatible(WITH_GHOST_SDL WITH_XR_OPENXR OFF)
WITH_GHOST_SDL working again (missing std:: update)
2012-03-13 14:28:58 +00:00
Build: Allow UI tests to run locally on all platforms This commit allows the `WITH_UI_TESTS` CMake option to be used on all platforms, not only Linux. The existing functionality to use the Weston compositor was moved into the `WITH_UI_TESTS_HEADLESS` option. When these tests are run with only `WITH_UI_TESTS`, a visible instance of Blender is opened up for testing. Pull Request: https://projects.blender.org/blender/blender/pulls/135889
2025-03-14 22:27:50 +01:00
if(WITH_UI_TESTS_HEADLESS)
set_and_warn_dependency(WITH_GHOST_WAYLAND WITH_UI_TESTS_HEADLESS OFF)
Tests: support running graphical tests as part of CTests User a Blender wrapper `tests/utils/blender_headless.py` to runs a graphical instance of Blender within a headless weston compositor. Currently only WAYLAND is supported as a back-end, support for other platforms is possible. The tests can run from X11 since the tests don't depend on existing instances of X11 or WAYLAND. - Each test runs a separate headless instance of WESTON since the overhead is minimal, this allows tests to run in parallel without interfering with each other. - There is a CMake option WESTON_BIN, when left empty the weston from LIBDIR is used. Otherwise this can point to the weston binary installed on the users system. - In most cases simulated events are needed to implement these tests (running blender with `--enable-event-simulate`). - This commit adds 14 undo tests - simulating user interaction as well as undo/redo actions, ensuring the desired result is reached. Other kinds of UI tests could be added in the future. Ref !114164
2023-10-26 15:19:33 +11:00
endif()
CMake: Avoid call of find_package(Git) for every compile with buildinfo enabled This is a bit tricky, find_package(Git) was only used to check if git is installed and actual git command was assumed to be in the PATH (while ideally it should have been GIT_COMMAND variable). This commit makes re-compile output cleaner, especially when using Ninja. Adding proper GIT_COMMAND to buildinfo.cmake is also possible via argument. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D1847
2016-03-11 13:05:44 +05:00
if(WITH_BUILDINFO)
find_package(Git)
Build: add option to error when features can't be enabled This is to help ensure buildbot builds are correct, while still gracefully disabling features in user/developer builds. * Add WITH_STRICT_BUILD_OPTIONS to give an error when features can't be enabled due to missing libraries or other reasons. Add new macro set_and_warn_library_found used everywhere features were being automatically disabled. * Remove code from Windows and macOS for various libraries that would automatically disable features. set_and_warn_library_found could be used here also, but we are generally assuming the precompiled libraries are complete and only test for availability when libraries are just added. Differential Revision: https://developer.blender.org/D16104
2022-09-29 19:01:35 +02:00
set_and_warn_library_found("Git" GIT_FOUND WITH_BUILDINFO)
CMake: Avoid call of find_package(Git) for every compile with buildinfo enabled This is a bit tricky, find_package(Git) was only used to check if git is installed and actual git command was assumed to be in the PATH (while ideally it should have been GIT_COMMAND variable). This commit makes re-compile output cleaner, especially when using Ninja. Adding proper GIT_COMMAND to buildinfo.cmake is also possible via argument. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D1847
2016-03-11 13:05:44 +05:00
endif()
Audaspace: fixing problems for the merge to master suggested by Campbell and Sergey. - rename WITH_EXTERNAL_AUDASPACE to WITH_SYSTEM_AUDASPACE. - rename C/PYAUDASPACE to AUDASPACE_C/PY - simplifying cmake defines and includes. - fixing include paths and enabling WITH_SYSTEM_AUDASPACE for windows. - fixing scons building. - other minor build system fixes.
2015-06-16 10:03:35 +02:00
if(WITH_AUDASPACE)
Audaspace: Moving audaspace 1.3 into extern. Deleting the old internal audaspace. Major changes from there are: - The whole library was refactored to use C++11. - Many stability and performance improvements. - Major Python API refactor: - Most requested: Play self generated sounds using numpy arrays. - For games: Sound list, random sounds and dynamic music. - Writing sounds to files. - Sequencing API. - Opening sound devices, eg. Jack. - Ability to choose different OpenAL devices in the user settings.
2017-08-18 08:24:12 +02:00
if(NOT WITH_SYSTEM_AUDASPACE)
CMake: wrap long lines, especially option descriptions Wrap text to fit in the column width and encourage descriptive text.
2023-08-10 00:51:35 +10:00
set(AUDASPACE_C_INCLUDE_DIRS
"${CMAKE_SOURCE_DIR}/extern/audaspace/bindings/C"
"${CMAKE_BINARY_DIR}/extern/audaspace"
)
set(AUDASPACE_PY_INCLUDE_DIRS
"${CMAKE_SOURCE_DIR}/extern/audaspace/bindings"
)
Audaspace: fixing problems for the merge to master suggested by Campbell and Sergey. - rename WITH_EXTERNAL_AUDASPACE to WITH_SYSTEM_AUDASPACE. - rename C/PYAUDASPACE to AUDASPACE_C/PY - simplifying cmake defines and includes. - fixing include paths and enabling WITH_SYSTEM_AUDASPACE for windows. - fixing scons building. - other minor build system fixes.
2015-06-16 10:03:35 +02:00
endif()
endif()
CMake: Fix cimpilation error when CUDA dynload is disabled but toolkit is not installed
2018-02-14 10:20:26 +01:00
# Auto-enable CUDA dynload if toolkit is not found.
Build: don't look for CUDA toolkit if not using Cycles CUDA device
2021-12-07 19:51:39 +01:00
if(WITH_CYCLES AND WITH_CYCLES_DEVICE_CUDA AND NOT WITH_CUDA_DYNLOAD)
CMake: Fix cimpilation error when CUDA dynload is disabled but toolkit is not installed
2018-02-14 10:20:26 +01:00
find_package(CUDA)
Cleanup: style, indentation
2019-06-19 07:24:55 +10:00
if(NOT CUDA_FOUND)
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
message(
STATUS
"CUDA toolkit not found, "
"using dynamic runtime loading of libraries (WITH_CUDA_DYNLOAD) instead"
)
CMake: Fix cimpilation error when CUDA dynload is disabled but toolkit is not installed
2018-02-14 10:20:26 +01:00
set(WITH_CUDA_DYNLOAD ON)
endif()
endif()
Cycles: add HIP device support for AMD GPUs NOTE: this feature is not ready for user testing, and not yet enabled in daily builds. It is being merged now for easier collaboration on development. HIP is a heterogenous compute interface allowing C++ code to be executed on GPUs similar to CUDA. It is intended to bring back AMD GPU rendering support on Windows and Linux. https://github.com/ROCm-Developer-Tools/HIP. As of the time of writing, it should compile and run on Linux with existing HIP compilers and driver runtimes. Publicly available compilers and drivers for Windows will come later. See task T91571 for more details on the current status and work remaining to be done. Credits: Sayak Biswas (AMD) Arya Rafii (AMD) Brian Savery (AMD) Differential Revision: https://developer.blender.org/D12578
2021-09-28 16:51:14 +02:00
if(WITH_CYCLES_DEVICE_HIP)
# Currently HIP must be dynamically loaded, this may change in future toolkits
set(WITH_HIP_DYNLOAD ON)
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Check if Sub-modules are Cloned
documentation edit to address bmesh py api bug [#30453] warn when addons are not found when running cmake.
2012-03-14 00:30:20 +00:00
if(WITH_PYTHON)
Refactor: Move BPY `generic` headers to proper C++ ones. NOTE: `bgl.h` was left unchanged, as it is deprecated code anyway, and its conversion to C++ does not seem immediately trivial.
2024-09-24 15:25:36 +02:00
# While we have this as an '#error' in 'bpy_capi_utils.hh',
CMake: Re-order PYTHON_VERSION check Missing paths would error first.
2017-10-08 14:00:42 +11:00
# upgrading Python tends to cause confusion for users who build.
# Give the error message early to make this more obvious.
#
# Do this before main 'platform_*' checks,
# because UNIX will search for the old Python paths which may not exist.
# giving errors about missing paths before this case is met.
PyAPI: drop support for Python 3.10 All platforms have been updated to support 3.11 so supporting 3.10 is no longer needed.
2024-01-09 22:23:41 +11:00
if(DEFINED PYTHON_VERSION AND "${PYTHON_VERSION}" VERSION_LESS "3.11")
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
message(
FATAL_ERROR
PyAPI: drop support for Python 3.10 All platforms have been updated to support 3.11 so supporting 3.10 is no longer needed.
2024-01-09 22:23:41 +11:00
"At least Python 3.11 is required to build, but found Python ${PYTHON_VERSION}"
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
)
CMake: Re-order PYTHON_VERSION check Missing paths would error first.
2017-10-08 14:00:42 +11:00
endif()
documentation edit to address bmesh py api bug [#30453] warn when addons are not found when running cmake.
2012-03-14 00:30:20 +00:00
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# InitialIze Un-cached Vars, Avoid Unused Warning
cmake was using dna source list with the variable out of scope, possibly causing dependency problems.
2011-02-22 06:23:07 +00:00
build python module without binreloc, add dummy argv[0] to initialize bprogname.
2011-02-21 13:13:08 +00:00
# linux only, not cached
set(WITH_BINRELOC OFF)
Edits to user prefs NDOF UI Small changes: - Remove "NDOF" from each setting - Change tooltip for deadzone - Unrelated typo in cmake comment Reviewers: merwin, Severin Reviewed By: merwin, Severin Tags: #bf_blender, #user_interface Differential Revision: https://developer.blender.org/D2319
2016-12-29 01:09:11 -05:00
# MACOSX only, set to avoid uninitialized
cmake: - fix for cmake's SSE detection which would fail because of strict warnings and also had redundant cache setting. - was incorrectly initializing variables (own bad) - python was searching for libs on every run, now only do this if there not cached.
2011-10-01 19:52:33 +00:00
set(EXETYPE "")
cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for debug
2011-06-28 02:49:49 +00:00
# C/C++ flags
set(PLATFORM_CFLAGS)
cmake: correct uninitialized vars
2011-06-14 00:24:50 +00:00
cmake was using dna source list with the variable out of scope, possibly causing dependency problems.
2011-02-22 06:23:07 +00:00
# these are added to later on.
cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for debug
2011-06-28 02:49:49 +00:00
set(C_WARNINGS)
set(CXX_WARNINGS)
Cleanup: spelling & repeated words in comments Address warnings from check_spelling.py
2025-03-06 10:24:54 +11:00
# NOTE: These flags are intended for situations where it's impractical to
Cleanup: suppress 'address' warnings for ./extern/glew Also add comments noting why some warnings shouldn't be added to strict-flags.
2022-05-19 10:33:02 +10:00
# suppress warnings by modifying the code or for code which is maintained externally.
# For GCC this typically means adding `-Wno-*` arguments to negate warnings
# that are useful in the general case.
CMake: Cleanup, rename CC_REMOVE_STRICT_FLAGS to C_REMOVE_STRICT_FLAGS
2018-06-22 14:17:55 +02:00
set(C_REMOVE_STRICT_FLAGS)
CMake: Tweaks to removal of strict flags Silences the following strict flags from external libraries: - -Wclass-memaccess - -Wswitch - -Wtype-limits - -Wint-in-bool-context Needed to tweak macro a bit, since the old logic was wrong: we can not use CXX flags for C compiler, need way more strict separation between what goes where.
2018-06-22 14:07:55 +02:00
set(CXX_REMOVE_STRICT_FLAGS)
correct flags for older GCC's which dont suppport -Wno-deprecated-declarations, detect if the flag is supported before use
2011-10-30 04:48:00 +00:00
CMake: clean up setting of platform specific linker flags Set flags directly on the target, and use common function for all cases. This refactoring helps with the next commit for test executables. Ref D8714
2020-09-15 16:00:15 +02:00
# Libraries to link to targets in setup_platform_linker_libs
cmake: - fix for cmake's SSE detection which would fail because of strict warnings and also had redundant cache setting. - was incorrectly initializing variables (own bad) - python was searching for libs on every run, now only do this if there not cached.
2011-10-01 19:52:33 +00:00
set(PLATFORM_LINKLIBS "")
cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for debug
2011-06-28 02:49:49 +00:00
CMake: clean up setting of platform specific linker flags Set flags directly on the target, and use common function for all cases. This refactoring helps with the next commit for test executables. Ref D8714
2020-09-15 16:00:15 +02:00
# Added to target linker flags in setup_platform_linker_flags
cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for debug
2011-06-28 02:49:49 +00:00
# - CMAKE_EXE_LINKER_FLAGS
# - CMAKE_EXE_LINKER_FLAGS_DEBUG
cmake: - fix for cmake's SSE detection which would fail because of strict warnings and also had redundant cache setting. - was incorrectly initializing variables (own bad) - python was searching for libs on every run, now only do this if there not cached.
2011-10-01 19:52:33 +00:00
set(PLATFORM_LINKFLAGS "")
set(PLATFORM_LINKFLAGS_DEBUG "")
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 17:07:23 +11:00
set(PLATFORM_LINKFLAGS_RELEASE "")
set(PLATFORM_LINKFLAGS_EXECUTABLE "")
cmake was using dna source list with the variable out of scope, possibly causing dependency problems.
2011-02-22 06:23:07 +00:00
Tests: support generating code coverage report This only works with GCC and has only been tested on Linux. The main goal is to automatically generate the code coverage reports on the buildbot and to publish them. With some luck, this motivates people to increase test coverage in their respective areas. Nevertheless, it should be easy to generate the reports locally too (at least on supported software stacks). Usage: 1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE** enabled. 2. Run tests. This automatically generates `.gcda` files in the build directory. 3. Run `make/ninja coverage-report` in the build directory. If everything is successful, this will open a browser with the final report which is stored in `build-dir/coverage/report/`. For a bit more control one can also run `coverage.py` script directly. This allows passing in the `--no-browser` option which may be benefitial when running it on the buildbot. Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the line execution counts. The final report has a main entry point (`index.html`) and a separate `.html` file for every source code file that coverage data was available for. This also contains some code that is not in Blender's git repository. We could filter those out, but it also seems interesting (to me anyway), so I just kept it in. Doing the analysis and writing the report takes ~1 min. The slow part is running all tests in a debug build which takes ~12 min for me. Since the coverage data is fairly large and the report also includes the entire source code, file compression is used in two places: * The intermediate analysis results for each file are stored in compressed zip files. This data is still independent from the report html and could be used to build other tools on top of. I could imagine storing the analysis data for each day for example to gather greater insights into how coverage changes over time in different parts of the code. * The analysis data and source code is compressed and base64 encoded embedded into the `.html` files. This makes them much smaller than embedding the data without compression (5-10x). Pull Request: https://projects.blender.org/blender/blender/pulls/126181
2024-08-15 12:17:55 +02:00
if(WITH_COMPILER_CODE_COVERAGE)
CMake: Add code coverage support for clang Pretty bare bones but gets the job done, unlike the gcc tooling, this will work for release builds, the performance cost of it is on the high side of things, the full test suite tests take over an hour for me with code coverage support enabled on a release build. I have not timed a debug build. Given developers can just run their tests to get coverage data over what they are working on, I feel this is still useful tooling to have. This adds the 3 targets for clang and adds a single gcc target coverage-reset - this removes the collected code coverage data and report coverage-report - This merges the collected data and generates the report (new for gcc) coverage-show - This merges the collected data and generates the report and opens it in the browser This relies on llvm-cov and llvm-profdata being available if not found code coverage is disabled. Note: A full test run requires an obscene amount of disk space, a complete test run takes about 125GB and takes 12 minutes to merge, so provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly Example report in PR
2025-05-12 16:28:41 +02:00
if(CMAKE_COMPILER_IS_GNUCC)
# GCC only supports this on debug builds.
string(APPEND CMAKE_C_FLAGS_DEBUG " ${COMPILER_CODE_COVERAGE_CFLAGS}")
string(APPEND CMAKE_CXX_FLAGS_DEBUG " ${COMPILER_CODE_COVERAGE_CXXFLAGS}")
elseif(CMAKE_C_COMPILER_ID MATCHES "Clang")
# Clang will allow it on all builds.
string(APPEND CMAKE_C_FLAGS " ${COMPILER_CODE_COVERAGE_CFLAGS}")
string(APPEND CMAKE_CXX_FLAGS " ${COMPILER_CODE_COVERAGE_CXXFLAGS}")
endif()
Tests: support generating code coverage report This only works with GCC and has only been tested on Linux. The main goal is to automatically generate the code coverage reports on the buildbot and to publish them. With some luck, this motivates people to increase test coverage in their respective areas. Nevertheless, it should be easy to generate the reports locally too (at least on supported software stacks). Usage: 1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE** enabled. 2. Run tests. This automatically generates `.gcda` files in the build directory. 3. Run `make/ninja coverage-report` in the build directory. If everything is successful, this will open a browser with the final report which is stored in `build-dir/coverage/report/`. For a bit more control one can also run `coverage.py` script directly. This allows passing in the `--no-browser` option which may be benefitial when running it on the buildbot. Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the line execution counts. The final report has a main entry point (`index.html`) and a separate `.html` file for every source code file that coverage data was available for. This also contains some code that is not in Blender's git repository. We could filter those out, but it also seems interesting (to me anyway), so I just kept it in. Doing the analysis and writing the report takes ~1 min. The slow part is running all tests in a debug build which takes ~12 min for me. Since the coverage data is fairly large and the report also includes the entire source code, file compression is used in two places: * The intermediate analysis results for each file are stored in compressed zip files. This data is still independent from the report html and could be used to build other tools on top of. I could imagine storing the analysis data for each day for example to gather greater insights into how coverage changes over time in different parts of the code. * The analysis data and source code is compressed and base64 encoded embedded into the `.html` files. This makes them much smaller than embedding the data without compression (5-10x). Pull Request: https://projects.blender.org/blender/blender/pulls/126181
2024-08-15 12:17:55 +02:00
endif()
Cleanup: style, indentation
2019-06-19 07:24:55 +10:00
if(NOT CMAKE_BUILD_TYPE MATCHES "Release")
CMake: disable WITH_COMPILER_ASAN for CMAKE_BUILD_TYPE Release
2018-06-08 11:45:05 +02:00
if(WITH_COMPILER_ASAN)
CMake/macOS: Avoid passing compiler flags to try_compile. `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
2020-10-08 19:47:45 +05:30
if(NOT APPLE)
# Avoid passing address sanitizer compiler flags to `try_compile`.
# Since linker flags are not set, all compiler checks and `find_package`
# calls that rely on `try_compile` will fail.
# See CMP0066 also.
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND CMAKE_C_FLAGS_DEBUG " ${COMPILER_ASAN_CFLAGS}")
string(APPEND CMAKE_C_FLAGS_RELWITHDEBINFO " ${COMPILER_ASAN_CFLAGS}")
CMake/macOS: Avoid passing compiler flags to try_compile. `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
2020-10-08 19:47:45 +05:30
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND CMAKE_CXX_FLAGS_DEBUG " ${COMPILER_ASAN_CXXFLAGS}")
string(APPEND CMAKE_CXX_FLAGS_RELWITHDEBINFO " ${COMPILER_ASAN_CXXFLAGS}")
CMake/macOS: Avoid passing compiler flags to try_compile. `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
2020-10-08 19:47:45 +05:30
endif()
CMake: disable WITH_COMPILER_ASAN for CMAKE_BUILD_TYPE Release
2018-06-08 11:45:05 +02:00
if(MSVC)
Cleanup: trailing space in CMake files
2018-06-17 20:15:24 +02:00
set(COMPILER_ASAN_LINKER_FLAGS "/FUNCTIONPADMIN:6")
CMake: disable WITH_COMPILER_ASAN for CMAKE_BUILD_TYPE Release
2018-06-08 11:45:05 +02:00
endif()
macOS: Remove ASan debug flags from release config. 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.
2020-09-26 13:05:33 +05:30
if(APPLE AND COMPILER_ASAN_LIBRARY)
string(REPLACE " " ";" _list_COMPILER_ASAN_CFLAGS ${COMPILER_ASAN_CFLAGS})
Cleanup: Fix CMake syntax error in the last commit.
2020-12-02 13:55:52 +05:30
set(_is_CONFIG_DEBUG "$<OR:$<CONFIG:Debug>,$<CONFIG:RelWithDebInfo>>")
CMake/macOS: consider MinSizeRel too for ASan.
2020-12-02 13:23:25 +05:30
add_compile_options("$<${_is_CONFIG_DEBUG}:${_list_COMPILER_ASAN_CFLAGS}>")
Fix compilation error with WITH_COMPILER_ASAN=ON on macOS This change solves the following linker error: ld: warning: __eh_frame section too large (max 16MB) to encode dwarf unwind offsets in compact unwind table Proposed solution is to disable unwind table when building Blender with address sanitizer enabled. It is stated in the comment in the code, but to make it explicit there could some side-effects of code which relies on frame walking: - backtrace() - __attribute__((__cleanup__(f))) - __builtin_return_address(n), for n > 0 - pthread_cleanup_push when it is implemented using __attribute__((__cleanup__(f))) From the local tests it seems that backtrace() provides the same output as prior to this change (but with classic linker used, as prior to this change it is not possible to link Blender). The rest of the possibly functionality is not used by Blender, but it is a bit hard to tell if it is used by any of the dependent libraries. However, if the libraries are compiled dynamically, there will be no affect on them with this change. I am unable to run the full test suit as some of the tests are failing prior to this change with classic linker. Overall it seems to be no unwanted side effects on Blender development. Note that the change only affects debug builds with ASAN enabled, so it is a low risk of causing some real problem so might as well just give it a whirl and see if some unpredicted issue arises. Pull Request: https://projects.blender.org/blender/blender/pulls/116745
2024-01-03 16:39:05 +01:00
# Skip generation of the unwind tables, as they might require a lot of space when sanitizers
# are enabled and not fit into the .eh_frame section. Disabling the unwind tables might have
# side effects on code which does frame walking, such as
# - backtrace()
# - __attribute__((__cleanup__(f)))
# - __builtin_return_address(n), for n > 0
# - pthread_cleanup_push when it is implemented using __attribute__((__cleanup__(f)))
# It should not have affect on debugging, since it uses -g flag which generates debugging
# tables in the .debug_frame section.
# At the time of adding these flags calling backtrace() from C code on Apple M2 did not
# affect on the printed backtrace, and exception handling was correct as well.
#
# Related discussion:
Cleanup: line length in CMake files
2024-03-07 13:26:55 +11:00
# https://stackoverflow.com/questions/26300819
Fix compilation error with WITH_COMPILER_ASAN=ON on macOS This change solves the following linker error: ld: warning: __eh_frame section too large (max 16MB) to encode dwarf unwind offsets in compact unwind table Proposed solution is to disable unwind table when building Blender with address sanitizer enabled. It is stated in the comment in the code, but to make it explicit there could some side-effects of code which relies on frame walking: - backtrace() - __attribute__((__cleanup__(f))) - __builtin_return_address(n), for n > 0 - pthread_cleanup_push when it is implemented using __attribute__((__cleanup__(f))) From the local tests it seems that backtrace() provides the same output as prior to this change (but with classic linker used, as prior to this change it is not possible to link Blender). The rest of the possibly functionality is not used by Blender, but it is a bit hard to tell if it is used by any of the dependent libraries. However, if the libraries are compiled dynamically, there will be no affect on them with this change. I am unable to run the full test suit as some of the tests are failing prior to this change with classic linker. Overall it seems to be no unwanted side effects on Blender development. Note that the change only affects debug builds with ASAN enabled, so it is a low risk of causing some real problem so might as well just give it a whirl and see if some unpredicted issue arises. Pull Request: https://projects.blender.org/blender/blender/pulls/116745
2024-01-03 16:39:05 +01:00
add_compile_options("$<${_is_CONFIG_DEBUG}:-fno-unwind-tables>")
add_compile_options("$<${_is_CONFIG_DEBUG}:-fno-asynchronous-unwind-tables>")
add_compile_options("$<${_is_CONFIG_DEBUG}:-fno-omit-frame-pointer>")
CMake/macOS: consider MinSizeRel too for ASan.
2020-12-02 13:23:25 +05:30
add_link_options("$<${_is_CONFIG_DEBUG}:-fno-omit-frame-pointer;-fsanitize=address>")
macOS: Remove ASan debug flags from release config. 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.
2020-09-26 13:05:33 +05:30
unset(_list_COMPILER_ASAN_CFLAGS)
CMake/macOS: consider MinSizeRel too for ASan.
2020-12-02 13:23:25 +05:30
unset(_is_CONFIG_DEBUG)
macOS: Remove ASan debug flags from release config. 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.
2020-09-26 13:05:33 +05:30
elseif(COMPILER_ASAN_LIBRARY)
CMake: Refactor external dependencies handling This is a more correct fix to the issue Brecht was fixing in D6600. While the fix in that patch worked fine for linking it broke ASAN runtime under some circumstances. For example, `make full debug developer` would compile, but trying to start blender will cause assert failure in ASAN (related on check that ASAN is not running already). Top-level idea: leave it to CMake to keep track of dependency graph. The root of the issue comes to the fact that target like "blender" is configured to use a lot of static libraries coming from Blender sources and to use external static libraries. There is nothing which ensures order between blender's and external libraries. Only order of blender libraries is guaranteed. It was possible that due to a cycle or other circumstances some of blender libraries would have been passed to linker after libraries it uses, causing linker errors. For example, this order will likely fail: libbf_blenfont.a libfreetype6.a libbf_blenfont.a This change makes it so blender libraries are explicitly provided their dependencies to an external libraries, which allows CMake to ensure they are always linked against them. General rule here: if bf_foo depends on an external library it is to be provided to LIBS for bf_foo. For example, if bf_blenkernel depends on opensubdiv then LIBS in blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES. The change is made based on searching for used include folders such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries to LIBS ion that CMakeLists.txt. Transitive dependencies are not simplified by this approach, but I am not aware of any downside of this: CMake should be smart enough to simplify them on its side. And even if not, this shouldn't affect linking time. Benefit of not relying on transitive dependencies is that build system is more robust towards future changes. For example, if bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES and all such code is moved to bf_blenkernel this will not break linking. The not-so-trivial part is change to blender_add_lib (and its version in Cycles). The complexity is caused by libraries being provided as a single list argument which doesn't allow to use different release and debug libraries on Windows. The idea is: - Have every library prefixed as "optimized" or "debug" if separation is needed (non-prefixed libraries will be considered "generic"). - Loop through libraries passed to function and do simple parsing which will look for "optimized" and "debug" words and specify following library to corresponding category. This isn't something particularly great. Alternative would be to use target_link_libraries() directly, which sounds like more code but which is more explicit and allows to have more flexibility and control comparing to wrapper approach. Tested the following configurations on Linux, macOS and Windows: - make full debug developer - make full release developer - make lite debug developer - make lite release developer NOTE: Linux libraries needs to be compiled with D6641 applied, otherwise, depending on configuration, it's possible to run into duplicated zlib symbols error. Differential Revision: https://developer.blender.org/D6642
2020-01-20 18:36:19 +01:00
set(PLATFORM_LINKLIBS "${PLATFORM_LINKLIBS};${COMPILER_ASAN_LIBRARY}")
CMake: quiet uninitialized warnings
2023-08-17 11:53:56 +10:00
set(PLATFORM_LINKFLAGS "${COMPILER_ASAN_LIBRARY}")
set(PLATFORM_LINKFLAGS_DEBUG "${COMPILER_ASAN_LIBRARY}")
if(DEFINED COMPILER_ASAN_LINKER_FLAGS)
set(PLATFORM_LINKFLAGS "${PLATFORM_LINKFLAGS} ${COMPILER_ASAN_LINKER_FLAGS}")
set(PLATFORM_LINKFLAGS_DEBUG "${PLATFORM_LINKFLAGS_DEBUG} ${COMPILER_ASAN_LINKER_FLAGS}")
endif()
CMake: Refactor external dependencies handling This is a more correct fix to the issue Brecht was fixing in D6600. While the fix in that patch worked fine for linking it broke ASAN runtime under some circumstances. For example, `make full debug developer` would compile, but trying to start blender will cause assert failure in ASAN (related on check that ASAN is not running already). Top-level idea: leave it to CMake to keep track of dependency graph. The root of the issue comes to the fact that target like "blender" is configured to use a lot of static libraries coming from Blender sources and to use external static libraries. There is nothing which ensures order between blender's and external libraries. Only order of blender libraries is guaranteed. It was possible that due to a cycle or other circumstances some of blender libraries would have been passed to linker after libraries it uses, causing linker errors. For example, this order will likely fail: libbf_blenfont.a libfreetype6.a libbf_blenfont.a This change makes it so blender libraries are explicitly provided their dependencies to an external libraries, which allows CMake to ensure they are always linked against them. General rule here: if bf_foo depends on an external library it is to be provided to LIBS for bf_foo. For example, if bf_blenkernel depends on opensubdiv then LIBS in blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES. The change is made based on searching for used include folders such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries to LIBS ion that CMakeLists.txt. Transitive dependencies are not simplified by this approach, but I am not aware of any downside of this: CMake should be smart enough to simplify them on its side. And even if not, this shouldn't affect linking time. Benefit of not relying on transitive dependencies is that build system is more robust towards future changes. For example, if bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES and all such code is moved to bf_blenkernel this will not break linking. The not-so-trivial part is change to blender_add_lib (and its version in Cycles). The complexity is caused by libraries being provided as a single list argument which doesn't allow to use different release and debug libraries on Windows. The idea is: - Have every library prefixed as "optimized" or "debug" if separation is needed (non-prefixed libraries will be considered "generic"). - Loop through libraries passed to function and do simple parsing which will look for "optimized" and "debug" words and specify following library to corresponding category. This isn't something particularly great. Alternative would be to use target_link_libraries() directly, which sounds like more code but which is more explicit and allows to have more flexibility and control comparing to wrapper approach. Tested the following configurations on Linux, macOS and Windows: - make full debug developer - make full release developer - make lite debug developer - make lite release developer NOTE: Linux libraries needs to be compiled with D6641 applied, otherwise, depending on configuration, it's possible to run into duplicated zlib symbols error. Differential Revision: https://developer.blender.org/D6642
2020-01-20 18:36:19 +01:00
endif()
Add Asan support for clang on windows. This will currently only work for the RelWithDebInfo configuration since asan does not support the debug crt. for source line information in the reports, you need a copy of llvm-symbolizer in the blender folder or set the ASAN_SYMBOLIZER_PATH environment variable to point to it. Currently (as of 6.0.0) llvm-symbolizer does not ship with the binary clang/llvm distribution. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D3446
2018-05-31 11:50:30 -06:00
endif()
CMake: Add WITH_COMPILER_ASAN option This supports easy toggling of Address Sanitizer.
2018-05-18 15:21:18 +02:00
endif()
cmake was using dna source list with the variable out of scope, possibly causing dependency problems.
2011-02-22 06:23:07 +00:00
CMake: reduce Neon related output on Intel platforms * Only try to find sse2neon if Neon detected * Only run Neon support test once
2021-03-01 19:15:29 +01:00
# Test SIMD support, before platform includes to determine if sse2neon is needed.
if(WITH_CPU_SIMD)
CMake: Change build flags to use SSE42 if available This cleans up our `TEST_SSE_SUPPORT` macro to only test for SSE42 and passes the flags to the CMAKE_C/CXX_FLAGS the cpu check module needed to move to its own folder since the flags at the end of a CMakeLists.txt appear to be used for all targets inside a CMakeLists file and cpu_check cannot be build with sse42 flags. This only affects Mac/Linux since MSVC has no buildflags to target SSE42 Pull Request: https://projects.blender.org/blender/blender/pulls/118468
2024-04-11 20:46:14 +02:00
set(COMPILER_SSE42_FLAG)
CMake: reduce Neon related output on Intel platforms * Only try to find sse2neon if Neon detected * Only run Neon support test once
2021-03-01 19:15:29 +01:00
# Test Neon first since macOS Arm can compile and run x86-64 SSE binaries.
Cleanup: use lowercase function calls & macros in for CMake This is already the case for most CMake usage. Although some find modules are an exception to this, as they were originally maintained externally they use some different conventions. Also corrected bad indentation in: intern/cycles/CMakeLists.txt
2022-09-23 14:33:44 +10:00
test_neon_support()
CMake: reduce Neon related output on Intel platforms * Only try to find sse2neon if Neon detected * Only run Neon support test once
2021-03-01 19:15:29 +01:00
if(NOT SUPPORT_NEON_BUILD)
CMake: Change build flags to use SSE42 if available This cleans up our `TEST_SSE_SUPPORT` macro to only test for SSE42 and passes the flags to the CMAKE_C/CXX_FLAGS the cpu check module needed to move to its own folder since the flags at the end of a CMakeLists.txt appear to be used for all targets inside a CMakeLists file and cpu_check cannot be build with sse42 flags. This only affects Mac/Linux since MSVC has no buildflags to target SSE42 Pull Request: https://projects.blender.org/blender/blender/pulls/118468
2024-04-11 20:46:14 +02:00
test_sse_support(COMPILER_SSE42_FLAG)
CMake: reduce Neon related output on Intel platforms * Only try to find sse2neon if Neon detected * Only run Neon support test once
2021-03-01 19:15:29 +01:00
endif()
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
CMake: modify recent platform defaults Now only disable Jack and NDof on OSX Also comment main block for platform checks
2015-07-28 17:47:21 +10:00
# ----------------------------------------------------------------------------
# Main Platform Checks
#
# - UNIX
# - WIN32
# - APPLE
* Fix for compiling with cmake on OS X. Hopefully this goes ok for other platforms too.
2009-07-03 09:23:12 +00:00
if(UNIX AND NOT APPLE)
CMake: Move main platform checks to separate files Basically title says it all. The goal is to make platform maintenance easier, so you don't have to constantly scroll back and forth looking for if() branches to check which exact platform you're currently working on. Ideally we also would move option defaults to a platform files, but that i'm not sure how to implement in a nice way yet. Reviewers: mont29 Reviewed By: mont29 Differential Revision: https://developer.blender.org/D2148
2016-08-09 15:19:11 +02:00
include(platform_unix)
- check IF WIN32 AND NOT UNIX (for cygwin) - patch from Mike S to enable OpenMP and xcode
2010-11-21 13:41:43 +00:00
elseif(WIN32)
CMake: Move main platform checks to separate files Basically title says it all. The goal is to make platform maintenance easier, so you don't have to constantly scroll back and forth looking for if() branches to check which exact platform you're currently working on. Ideally we also would move option defaults to a platform files, but that i'm not sure how to implement in a nice way yet. Reviewers: mont29 Reviewed By: mont29 Differential Revision: https://developer.blender.org/D2148
2016-08-09 15:19:11 +02:00
include(platform_win32)
- check IF WIN32 AND NOT UNIX (for cygwin) - patch from Mike S to enable OpenMP and xcode
2010-11-21 13:41:43 +00:00
elseif(APPLE)
CMake: Move main platform checks to separate files Basically title says it all. The goal is to make platform maintenance easier, so you don't have to constantly scroll back and forth looking for if() branches to check which exact platform you're currently working on. Ideally we also would move option defaults to a platform files, but that i'm not sure how to implement in a nice way yet. Reviewers: mont29 Reviewed By: mont29 Differential Revision: https://developer.blender.org/D2148
2016-08-09 15:19:11 +02:00
include(platform_apple)
- check IF WIN32 AND NOT UNIX (for cygwin) - patch from Mike S to enable OpenMP and xcode
2010-11-21 13:41:43 +00:00
endif()
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Common Checks for Compatible Options
bugfix [#23257] cmake tests for SSE, but SSE2 gets enabled patch from Vinay Pawar, some minor changes by me.
2010-08-11 08:23:48 +00:00
Cleanup: use lowercase function calls & macros in for CMake This is already the case for most CMake usage. Although some find modules are an exception to this, as they were originally maintained externally they use some different conventions. Also corrected bad indentation in: intern/cycles/CMakeLists.txt
2022-09-23 14:33:44 +10:00
# Enable SIMD support if detected by `test_sse_support()` or `test_neon_support()`.
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
#
if(WITH_CPU_SIMD)
if(SUPPORT_NEON_BUILD)
# Neon
if(SSE2NEON_FOUND)
Build: fix gtest build flags affecting actual library Switch to target_ functions to avoid this.
2022-09-18 07:41:13 +02:00
include_directories(SYSTEM "${SSE2NEON_INCLUDE_DIRS}")
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
add_definitions(-DWITH_SSE2NEON)
endif()
else()
# SSE
CMake: Change build flags to use SSE42 if available This cleans up our `TEST_SSE_SUPPORT` macro to only test for SSE42 and passes the flags to the CMAKE_C/CXX_FLAGS the cpu check module needed to move to its own folder since the flags at the end of a CMakeLists.txt appear to be used for all targets inside a CMakeLists file and cpu_check cannot be build with sse42 flags. This only affects Mac/Linux since MSVC has no buildflags to target SSE42 Pull Request: https://projects.blender.org/blender/blender/pulls/118468
2024-04-11 20:46:14 +02:00
if(SUPPORT_SSE42_BUILD)
string(APPEND CMAKE_CXX_FLAGS " ${COMPILER_SSE42_FLAG}")
string(APPEND CMAKE_C_FLAGS " ${COMPILER_SSE42_FLAG}")
# MSVC doesn't define any of these and only does the AVX and higher flags.
# For consistency we define these flags for MSVC.
if(WIN32)
add_compile_definitions(
__MMX__
__SSE__
__SSE2__
__SSE3__
__SSE4_1__
__SSE4_2__
)
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
endif()
endif()
bugfix [#23257] cmake tests for SSE, but SSE2 gets enabled patch from Vinay Pawar, some minor changes by me.
2010-08-11 08:23:48 +00:00
endif()
CMake: quiet noisy messages on every run Printing that a library is found every time CMake runs isn't helpful. Restrict these messages for the first execution so messages are limited to information developers may need to know such as features being disabled because of incompatible configurations.
2023-10-07 18:20:30 +11:00
endif()
use lowercase for cmake builtin names and macros, remove contents in else() and endif() which is no longer needed.
2010-12-08 08:43:06 +00:00
CMake: quiet noisy messages on every run Printing that a library is found every time CMake runs isn't helpful. Restrict these messages for the first execution so messages are limited to information developers may need to know such as features being disabled because of incompatible configurations.
2023-10-07 18:20:30 +11:00
# Print instructions used on first run.
if(FIRST_RUN)
if(WITH_CPU_SIMD)
if(SUPPORT_NEON_BUILD)
if(SSE2NEON_FOUND)
message(STATUS "Neon SIMD instructions enabled")
else()
message(STATUS "Neon SIMD instructions detected but unused, requires sse2neon")
endif()
CMake: Change build flags to use SSE42 if available This cleans up our `TEST_SSE_SUPPORT` macro to only test for SSE42 and passes the flags to the CMAKE_C/CXX_FLAGS the cpu check module needed to move to its own folder since the flags at the end of a CMakeLists.txt appear to be used for all targets inside a CMakeLists file and cpu_check cannot be build with sse42 flags. This only affects Mac/Linux since MSVC has no buildflags to target SSE42 Pull Request: https://projects.blender.org/blender/blender/pulls/118468
2024-04-11 20:46:14 +02:00
elseif(SUPPORT_SSE42_BUILD)
message(STATUS "SSE42 SIMD instructions enabled")
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
else()
CMake: quiet noisy messages on every run Printing that a library is found every time CMake runs isn't helpful. Restrict these messages for the first execution so messages are limited to information developers may need to know such as features being disabled because of incompatible configurations.
2023-10-07 18:20:30 +11:00
message(STATUS "No SIMD instructions detected")
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
endif()
else()
CMake: quiet noisy messages on every run Printing that a library is found every time CMake runs isn't helpful. Restrict these messages for the first execution so messages are limited to information developers may need to know such as features being disabled because of incompatible configurations.
2023-10-07 18:20:30 +11:00
message(STATUS "SIMD instructions disabled")
BLI: use sse2neon to emulate SSE instructions with Arm Neon * WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon. * For macOS sse2neon.h is included as part of the precompiled libraries. * For Linux it is enabled if the sse2neon.h header file is detected. However this library does not have official releases and is not shipped with any Linux distribution, so manual installation and configuration is required to get this working. Ref D8237, T78710
2021-02-14 04:16:39 +01:00
endif()
endif()
cleanup endian handling - define __BIG_ENDIAN__ or __LITTLE_ENDIAN__ with cmake & scons. - ENDIAN_ORDER is now a define rather than a global short. - replace checks like this with single ifdef: #if defined(__sgi) || defined (__sparc) || defined (__sparc__) || defined (__PPC__) || defined (__ppc__) || defined (__hppa__) || defined (__BIG_ENDIAN__) - remove BKE_endian.h which isn't used
2011-09-19 08:02:17 +00:00
Big Endian Support Removal. This commit implements #125759. It removes: * Blender does not build on big endian systems anymore. * Support for opening blendfiles written from a big endian system is removed. It keeps: * Support to generate thumbnails from big endian blendfiles. * BE support in `extern` or `intern` libraries, including Cycles. * Support to open big endian versions of third party file formats: - PLY files. - Some image files (cineon, ...). Pull Request: https://projects.blender.org/blender/blender/pulls/140138
2025-06-12 10:37:47 +02:00
# Test endianness and set the endian define.
include(TestBigEndian)
test_big_endian(_SYSTEM_BIG_ENDIAN)
if(_SYSTEM_BIG_ENDIAN)
message(FATAL_ERROR "Blender does not support building on Big Endian systems" )
fix for building on windows, clear some warnings too
2011-09-27 01:32:27 +00:00
else()
Big Endian Support Removal. This commit implements #125759. It removes: * Blender does not build on big endian systems anymore. * Support for opening blendfiles written from a big endian system is removed. It keeps: * Support to generate thumbnails from big endian blendfiles. * BE support in `extern` or `intern` libraries, including Cycles. * Support to open big endian versions of third party file formats: - PLY files. - Some image files (cineon, ...). Pull Request: https://projects.blender.org/blender/blender/pulls/140138
2025-06-12 10:37:47 +02:00
add_definitions(-D__LITTLE_ENDIAN__)
cleanup endian handling - define __BIG_ENDIAN__ or __LITTLE_ENDIAN__ with cmake & scons. - ENDIAN_ORDER is now a define rather than a global short. - replace checks like this with single ifdef: #if defined(__sgi) || defined (__sparc) || defined (__sparc__) || defined (__PPC__) || defined (__ppc__) || defined (__hppa__) || defined (__BIG_ENDIAN__) - remove BKE_endian.h which isn't used
2011-09-19 08:02:17 +00:00
endif()
Big Endian Support Removal. This commit implements #125759. It removes: * Blender does not build on big endian systems anymore. * Support for opening blendfiles written from a big endian system is removed. It keeps: * Support to generate thumbnails from big endian blendfiles. * BE support in `extern` or `intern` libraries, including Cycles. * Support to open big endian versions of third party file formats: - PLY files. - Some image files (cineon, ...). Pull Request: https://projects.blender.org/blender/blender/pulls/140138
2025-06-12 10:37:47 +02:00
unset(_SYSTEM_BIG_ENDIAN)
build options to disable image formats WITH_CINEON, WITH_HDR. - updated cmake, make & scons. - renamed CMake build options WITH_TIFF -> WITH_IMAGE_TIFF, same for DDS, OPENJPEG etc.
2010-08-03 11:25:34 +00:00
if(WITH_IMAGE_OPENJPEG)
CMake: Attempt to fix compilation error on Windows after recent changes
2015-09-17 14:17:00 +05:00
# Special handling of Windows platform where openjpeg is always static.
if(WIN32)
set(OPENJPEG_DEFINES "-DOPJ_STATIC")
Build: require OpenJPEG 2.x minimum, remove bundled version. * WITH_SYSTEM_OPENJPEG is removed and is now always on, this was already the case for macOS and Windows. * This should not break existing Linx builds. If there is no new enough OpenJPEG installed, CMake will no find libopenjp2 and WITH_IMAGE_OPENJPEG will be disabled. * install_deps.sh was updated with new package names, since distributions put this version in a new package. Differential Revision: https://developer.blender.org/D3663
2018-08-30 14:20:19 +02:00
else()
set(OPENJPEG_DEFINES "")
CMake: Attempt to fix compilation error on Windows after recent changes
2015-09-17 14:17:00 +05:00
endif()
build options to disable image formats WITH_CINEON, WITH_HDR. - updated cmake, make & scons. - renamed CMake build options WITH_TIFF -> WITH_IMAGE_TIFF, same for DDS, OPENJPEG etc.
2010-08-03 11:25:34 +00:00
endif()
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
CMake: unbundle eigen3 Optionally use systems eigen3 library. T41989 by @hasufell with edits
2015-03-19 15:41:41 +11:00
if(NOT WITH_SYSTEM_EIGEN3)
set(EIGEN3_INCLUDE_DIRS ${CMAKE_SOURCE_DIR}/extern/Eigen3)
endif()
WebPlugin fix: * web plugin works on opera too sandboxing: * added AppArmor configuration * enabled privilege separation for the web plugin: the blender player can run as a lower privileged user, xauth token is generated on the fly . testing: * web plugin tested on ubuntu 32/64bit, fedora and FreeBSD Changed only cmake build script: AppArmor is enabled by default, if you want to enable privilege separation instead, you have to change the cmake variable WEBPLUGIN_SANDBOX_MODE to privsep (or none to disable it). Warning: source/gameengine/GamePlayer/xembed/blenderplayer-wrapper.c must be setuid root in order to change user successfully
2008-10-07 17:13:35 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Configure Metal
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
if(WITH_METAL_BACKEND)
Metal: Initial Implementation of Metal Backend for GPU Module. Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths. Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly. Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder Ref T96261 Reviewed By: fclem Maniphest Tasks: T96261 Differential Revision: https://developer.blender.org/D14293
2022-03-22 12:38:28 +01:00
add_definitions(-DWITH_METAL_BACKEND)
# No need to add frameworks here, all the ones we need for Metal and
# Metal-OpenGL Interop are already being added by
# build_files/cmake/platform/platform_apple.cmake
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
add option WITH_SYSTEM_BULLET to link against the bullet installation found on the system. Note: this doesn't work yet for everything with latest stable bullet (2.81), need to look into why and likely apply some patches upstream. However I managed to link blender by disabling some features, likely it can be made to work without too much trouble.
2013-01-03 00:23:52 +00:00
# Configure Bullet
CMake: use BULLET_LIBRARIES for both extern_bullet and system libraries There was no need to differentiate between these and it made the CMake files more verbose.
2023-01-19 17:07:21 +11:00
if(WITH_BULLET)
if(WITH_SYSTEM_BULLET)
find_package(Bullet)
set_and_warn_library_found("Bullet" BULLET_FOUND WITH_BULLET)
else()
set(BULLET_INCLUDE_DIRS "${CMAKE_SOURCE_DIR}/extern/bullet2/src")
set(BULLET_LIBRARIES "extern_bullet")
endif()
add option WITH_SYSTEM_BULLET to link against the bullet installation found on the system. Note: this doesn't work yet for everything with latest stable bullet (2.81), need to look into why and likely apply some patches upstream. However I managed to link blender by disabling some features, likely it can be made to work without too much trouble.
2013-01-03 00:23:52 +00:00
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Configure Python
support for blender as a module on win32.
2011-03-24 00:14:49 +00:00
CMake: use set_and_warn_incompatible macro
2023-10-07 19:28:36 +11:00
# Not currently supported due to different required Python link flags.
set_and_warn_incompatible(WITH_PYTHON_MODULE WITH_GTESTS OFF)
support for blender as a module on win32.
2011-03-24 00:14:49 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Configure `GLog/GFlags`
Move GLog/GFlags to extern/ This is where the libraries belongs to actually, they are not only used by Libmv now, but also by tests and Cycles.
2016-01-04 16:47:36 +05:00
Cycles: Remove glog dependency, redirect logs to CLOG * Add own simple logging system to replace glog, which is no longer maintained by Google. * When building in Blender, integrate with CLOG and print all messages through that system instead. * --log cycles now replaces --debug-cycles. The latter still works but is no longer documented. Pull Request: https://projects.blender.org/blender/blender/pulls/140244
2025-06-12 02:19:57 +02:00
if(WITH_LIBMV OR WITH_GTESTS)
CMake: Add option to link against system-wide Gflags library It is disabled by default, so should not affect existing configurations. Main benefits of this goes as: - Linux distros can use that to avoid libraries duplication and link blender package against gflags package from the system. - It it easier to test whether Blender works with updated version of Gflags prior to re-bundling the library.
2017-04-21 10:58:01 +02:00
if(WITH_SYSTEM_GFLAGS)
find_package(Gflags)
if(NOT GFLAGS_FOUND)
message(FATAL_ERROR "System wide Gflags is requested but was not found")
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# `FindGflags` does not define this, and we are not even sure what to use here.
CMake: Add option to link against system-wide Gflags library It is disabled by default, so should not affect existing configurations. Main benefits of this goes as: - Linux distros can use that to avoid libraries duplication and link blender package against gflags package from the system. - It it easier to test whether Blender works with updated version of Gflags prior to re-bundling the library.
2017-04-21 10:58:01 +02:00
set(GFLAGS_DEFINES)
else()
set(GFLAGS_DEFINES
-DGFLAGS_DLL_DEFINE_FLAG=
-DGFLAGS_DLL_DECLARE_FLAG=
-DGFLAGS_DLL_DECL=
)
set(GFLAGS_NAMESPACE "gflags")
set(GFLAGS_LIBRARIES extern_gflags)
set(GFLAGS_INCLUDE_DIRS "${PROJECT_SOURCE_DIR}/extern/gflags/src")
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: Add option to build against system-wide Glog Similar to previous commit for Gflags.
2017-04-21 14:26:25 +02:00
if(WITH_SYSTEM_GLOG)
find_package(Glog)
if(NOT GLOG_FOUND)
message(FATAL_ERROR "System wide Glog is requested but was not found")
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# `FindGlog` does not define this, and we are not even sure what to use here.
CMake: Add option to build against system-wide Glog Similar to previous commit for Gflags.
2017-04-21 14:26:25 +02:00
set(GLOG_DEFINES)
else()
set(GLOG_DEFINES
-DGOOGLE_GLOG_DLL_DECL=
)
set(GLOG_LIBRARIES extern_glog)
if(WIN32)
set(GLOG_INCLUDE_DIRS ${CMAKE_SOURCE_DIR}/extern/glog/src/windows)
else()
Glog/gflags: Reduce amount of local modifications With better directory layout and more proper include statements we can avoid several local modifications, such as changing config.h for Windows Glog and the ones related on pass-through statements in logging headers in Glog. This commit also makes unused functions not-a-warning for external code.
2018-03-23 14:32:18 +01:00
set(GLOG_INCLUDE_DIRS ${CMAKE_SOURCE_DIR}/extern/glog/include)
CMake: Add option to build against system-wide Glog Similar to previous commit for Gflags.
2017-04-21 14:26:25 +02:00
endif()
endif()
Move GLog/GFlags to extern/ This is where the libraries belongs to actually, they are not only used by Libmv now, but also by tests and Cycles.
2016-01-04 16:47:36 +05:00
endif()
CMake: Modernize the optional TBB dependency This continues the cmake modernization effort and introduces support for allowing our optional dependencies to integrate properly. TBB is added here as it's proven troublesome to maintain correctly. Currently the only Blender project which uses the TBB headers directly is `blenlib`. However, all downstream projects which require blenlib as their dependency, and wish to properly make use of its threading facilities, needed to define various TBB items in their CMake files. Not only is this unnecessary and arcane, but several projects didn't do this and ended up not using threading as well as producing ODR violations along the way[1]. This PR makes TBB a modern dependency and exposes it PUBLIC'ly from `blenlib`. All downstream projects which depend on blenlib will now receive everything they require from TBB automatically. This includes the `WITH_TBB` define, the headers, and the library itself. [1] blender/blender@05241f47f57d66763ae3b3b641741426c4787ba0 Pull Request: https://projects.blender.org/blender/blender/pulls/124916
2024-07-19 23:30:56 +02:00
# -----------------------------------------------------------------------------
# Common dependency targets
include(dependency_targets)
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Ninja Job Limiting
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
# Extra limits to number of jobs running in parallel for some kind os tasks.
# Only supported by Ninja build system currently.
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
if("${CMAKE_GENERATOR}" MATCHES "Ninja" AND WITH_NINJA_POOL_JOBS)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
message(STATUS "Using NINJA_POOL_JOBS:")
if(NOT NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS)
set(NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS "0" CACHE STRING "\
Define the maximum number of concurrent regular compilation jobs, for ninja build system. \
Keep at '0' to automatically compute optimal values for each build."
FORCE
)
mark_as_advanced(NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS)
endif()
if(NOT NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS)
set(NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS "0" CACHE STRING "\
Define the maximum number of concurrent memory-heavy compilation jobs, for ninja build system. \
Keep at '0' to automatically compute optimal values for each build."
FORCE
)
mark_as_advanced(NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS)
endif()
if(NOT NINJA_MAX_NUM_PARALLEL_LINK_JOBS)
set(NINJA_MAX_NUM_PARALLEL_LINK_JOBS "0" CACHE STRING "\
Define the maximum number of concurrent link jobs, for ninja build system. \
Keep at '0' to automatically compute optimal values for each build."
FORCE
)
mark_as_advanced(NINJA_MAX_NUM_PARALLEL_LINK_JOBS)
endif()
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
# Try to compute good default values,
# unless some are enforced in the user-exposed CMake cached variables.
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
cmake_host_system_information(RESULT _NUM_CORES QUERY NUMBER_OF_LOGICAL_CORES)
# Note: this gives mem in MB.
cmake_host_system_information(RESULT _TOT_MEM QUERY TOTAL_PHYSICAL_MEMORY)
set(_link_jobs 0)
if(NINJA_MAX_NUM_PARALLEL_LINK_JOBS)
set(_link_jobs ${NINJA_MAX_NUM_PARALLEL_LINK_JOBS})
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(STATUS
" NINJA_MAX_NUM_PARALLEL_LINK_JOBS: "
"max concurrent linking jobs (from settings): ${_link_jobs}"
)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
endif()
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
if(${_link_jobs} LESS 1)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
# Heuristics: Maximum amount of memory needed per linking task.
# Note: These values are purposedly over-estimated by 10-15% at least, to account
# for other types of jobs' memory usage, other system memory usages, etc.
set(_link_mem 10000)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
if(WITH_COMPILER_ASAN)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_link_mem 30000)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
elseif("${CMAKE_BUILD_TYPE}" MATCHES "Debug")
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_link_mem 20000)
endif()
# In practice, even when there is RAM available,
# more than 2 linking tasks running in parallel gets slower (due to slow disks accesses).
if(${_NUM_CORES} GREATER 7)
set(_link_jobs_max 2)
else()
set(_link_jobs_max 1)
endif()
math(EXPR _link_jobs "${_TOT_MEM} / ${_link_mem}")
if(${_link_jobs} GREATER ${_link_jobs_max})
set(_link_jobs ${_link_jobs_max})
elseif(${_link_jobs} LESS 1)
set(_link_jobs 1)
endif()
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(STATUS
" NINJA_MAX_NUM_PARALLEL_LINK_JOBS: "
"max concurrent linking jobs (computed): ${_link_jobs}"
)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_link_mem)
set(_link_jobs_max)
endif()
set_property(
GLOBAL APPEND PROPERTY
JOB_POOLS link_job_pool=${_link_jobs}
)
set(CMAKE_JOB_POOL_LINK link_job_pool)
set(_compile_heavy_jobs 0)
if(NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS)
set(_compile_heavy_jobs ${NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS})
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(STATUS
" NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS: "
"max concurrent heavy compile jobs (from settings): ${_compile_heavy_jobs}"
)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
endif()
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
if(${_compile_heavy_jobs} LESS 1)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
# Heuristics: Maximum amount of memory needed per heavy compile task.
# Note: These values are purposedly over-estimated by 10-15% at least, to account
# for other types of jobs' memory usage, other system memory usages, etc.
set(_compile_heavy_mem 2000)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
if(WITH_COMPILER_ASAN)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_heavy_mem 15000)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
elseif("${CMAKE_BUILD_TYPE}" MATCHES "Debug")
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_heavy_mem 2000)
endif()
math(EXPR _compile_heavy_jobs "${_TOT_MEM} / ${_compile_heavy_mem}")
if(${_NUM_CORES} GREATER 3)
# Heuristics: Cap max number of heavy compile jobs to 80% the amount of available cores,
# to ensure neither linking nor regular compile jobs are starved from cores.
# It also ensures that even if there would be enough RAM, the machine never ends up
# handling only heavy jobs at some point.
# This can have annoying sides effects, like lack of output in the console for several
# minutes, which can lead to a wrong detection of 'unresponsive' state by the build-bots e.g.
math(EXPR _compile_heavy_jobs_max "(${_NUM_CORES} * 8) / 10")
else()
set(_compile_heavy_jobs_max ${_NUM_CORES})
endif()
Build: Ninja: tweak pooljobs default settings. This commit simplifies and makes more generic the computation of the maximum number of parallel heavy build jobs. Essentially, it allows 1 heavy job per 8Gb of RAM. It also systematically sets the amount of heavy jobs, since we are going to get more of these in the future (like the 'unity build' units), the previous heuristic had some loose ends (e,g for a 40Gb RAM, 16 threads machine, it would not set any limit to heavy jobs, yet said machine would likely not be able to run 16 3.5+Gb heavy jobs in parallel...). This is some initial step towards a better handling of 'sanitizer' builds on the Blender buildbot.
2024-01-05 12:22:00 +01:00
if(${_compile_heavy_jobs} GREATER ${_compile_heavy_jobs_max})
Build: Ninja: Use similar logic for default heavy and regular jobs amount. Update the regular jobs amount computation to follow the same logic as for the heavy ones. the main difference is that it uses a '2Gb of RAM per job' base value. This change is mainly targetted at machines with a relatively low RAM/cores ratio, since even regular compile jobs can end up using quite a lot of RAM if many are running in parallel, previous defaults would likely not work well on machines with e.g. 16Gb of RAM and 16 cores. Also fix a typo in previous commit (6493d0233c), sorry about that.
2024-01-05 12:51:47 +01:00
set(_compile_heavy_jobs ${_compile_heavy_jobs_max})
Build: Ninja: tweak pooljobs default settings. This commit simplifies and makes more generic the computation of the maximum number of parallel heavy build jobs. Essentially, it allows 1 heavy job per 8Gb of RAM. It also systematically sets the amount of heavy jobs, since we are going to get more of these in the future (like the 'unity build' units), the previous heuristic had some loose ends (e,g for a 40Gb RAM, 16 threads machine, it would not set any limit to heavy jobs, yet said machine would likely not be able to run 16 3.5+Gb heavy jobs in parallel...). This is some initial step towards a better handling of 'sanitizer' builds on the Blender buildbot.
2024-01-05 12:22:00 +01:00
elseif(${_compile_heavy_jobs} LESS 1)
set(_compile_heavy_jobs 1)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
endif()
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(STATUS
" NINJA_MAX_NUM_PARALLEL_COMPILE_HEAVY_JOBS: "
"max concurrent heavy compile jobs (computed): ${_compile_heavy_jobs}"
)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_heavy_mem)
Build: Ninja: Use similar logic for default heavy and regular jobs amount. Update the regular jobs amount computation to follow the same logic as for the heavy ones. the main difference is that it uses a '2Gb of RAM per job' base value. This change is mainly targetted at machines with a relatively low RAM/cores ratio, since even regular compile jobs can end up using quite a lot of RAM if many are running in parallel, previous defaults would likely not work well on machines with e.g. 16Gb of RAM and 16 cores. Also fix a typo in previous commit (6493d0233c), sorry about that.
2024-01-05 12:51:47 +01:00
set(_compile_heavy_jobs_max)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
endif()
set_property(
GLOBAL APPEND PROPERTY
JOB_POOLS compile_heavy_job_pool=${_compile_heavy_jobs}
)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_jobs 0)
if(NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS)
set(_compile_jobs ${NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS})
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(STATUS
" NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS: "
"max concurrent regular compile jobs (from settings): ${_compile_jobs}"
)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
endif()
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
if(${_compile_jobs} LESS 1)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
# Heuristics: Maximum amount of memory needed per regular compile task.
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
# NOTE: These values are purposefully over-estimated by 10-15% at least,
# to account for other types of jobs' memory usage, other system memory usages, etc.
Build: Ninja: Use similar logic for default heavy and regular jobs amount. Update the regular jobs amount computation to follow the same logic as for the heavy ones. the main difference is that it uses a '2Gb of RAM per job' base value. This change is mainly targetted at machines with a relatively low RAM/cores ratio, since even regular compile jobs can end up using quite a lot of RAM if many are running in parallel, previous defaults would likely not work well on machines with e.g. 16Gb of RAM and 16 cores. Also fix a typo in previous commit (6493d0233c), sorry about that.
2024-01-05 12:51:47 +01:00
#
CMake: Further increase RAM threshold for regular compile jobs. Not great, but the alternative solution (putting several 'main' targets, like `bf_blenkernel`, into the heavy compile pool, would be even worse).
2025-07-08 17:33:03 +02:00
# FIXME:
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
# There are a few files in 'normal' compile job pool now
# that require a significant amount of RAM
# (e.g. `blenkernel/intern/volume.cc` can require almost 5GB of RAM in debug + ASAN builds).
# Until we can add individual files to the heavy compile pool job
# (not possible currently with CMake), using overly-big
# values in ASAN build cases is the best that can be done.
# Alternative solution would be to put several whole targets (like `bf_blenkernel`)
# into the heavy pool, but that is likely even worse of a workaround.
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_mem 500)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
if(WITH_COMPILER_ASAN)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_mem 4000)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
elseif("${CMAKE_BUILD_TYPE}" MATCHES "Debug")
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_mem 500)
endif()
math(EXPR _compile_jobs "${_TOT_MEM} / ${_compile_mem}")
Build: Ninja: Use similar logic for default heavy and regular jobs amount. Update the regular jobs amount computation to follow the same logic as for the heavy ones. the main difference is that it uses a '2Gb of RAM per job' base value. This change is mainly targetted at machines with a relatively low RAM/cores ratio, since even regular compile jobs can end up using quite a lot of RAM if many are running in parallel, previous defaults would likely not work well on machines with e.g. 16Gb of RAM and 16 cores. Also fix a typo in previous commit (6493d0233c), sorry about that.
2024-01-05 12:51:47 +01:00
if(${_NUM_CORES} GREATER 3)
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
# Heuristics: Cap max number of regular compile jobs
# to less than the total available amount of cores,
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
# to ensure neither linking nor heavy compile jobs are starved from cores.
math(EXPR _compile_jobs_max "${_NUM_CORES} - ${_link_jobs} - (${_compile_heavy_jobs} / 8)")
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
else()
Build: Ninja: Use similar logic for default heavy and regular jobs amount. Update the regular jobs amount computation to follow the same logic as for the heavy ones. the main difference is that it uses a '2Gb of RAM per job' base value. This change is mainly targetted at machines with a relatively low RAM/cores ratio, since even regular compile jobs can end up using quite a lot of RAM if many are running in parallel, previous defaults would likely not work well on machines with e.g. 16Gb of RAM and 16 cores. Also fix a typo in previous commit (6493d0233c), sorry about that.
2024-01-05 12:51:47 +01:00
set(_compile_jobs_max ${_NUM_CORES})
endif()
if(${_compile_jobs} GREATER ${_compile_jobs_max})
set(_compile_jobs ${_compile_jobs_max})
elseif(${_compile_jobs} LESS 1)
set(_compile_jobs 1)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
endif()
Cleanup: format CMake files Wrap long lines, correct typos, simpler line wrapping for messages.
2025-07-22 16:05:27 +10:00
message(STATUS
" NINJA_MAX_NUM_PARALLEL_COMPILE_JOBS: "
"max concurrent regular compile jobs (computed): ${_compile_jobs}"
)
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_compile_mem)
set(_compile_jobs_max)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
endif()
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set_property(
GLOBAL APPEND PROPERTY
JOB_POOLS compile_job_pool=${_compile_jobs}
)
set(CMAKE_JOB_POOL_COMPILE compile_job_pool)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
CMake Ninja Jobs: Better auto-compute of jobs values. This refactor the previous system, main changes being: * The `NINJA_MAX_NUM_PARALLEL_..._JOBS` variables are now only to allow users to override automatic values with their own settings. * If undefined or left at the new '0' default, CMake will compute 'optimal' values for all three pools, based on the amount of available RAM, cores, and the type of build. * Linking jobs can now max up at 2 instead of 1. Pull Request: https://projects.blender.org/blender/blender/pulls/142112
2025-07-21 15:48:27 +02:00
set(_link_jobs)
set(_compile_heavy_jobs)
set(_compile_jobs)
set(_NUM_CORES)
set(_TOT_MEM)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
endif()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Extra Compile Flags
define NDEBUG for release builds so assert() is disabled.
2010-10-18 12:35:40 +00:00
- fixed remaining unused warnings. - omit render code from this warning (cmake only), until render branch is merged. - moved -Wunused-parameter warning to apply to all C code in blender (not just ./source/blender), (cmake only).
2010-10-17 06:38:56 +00:00
if(CMAKE_COMPILER_IS_GNUCC)
CMake now tests warnings are supported, GCC 4.0 wasn't working because of unsupported warnings. this can work for other compilers too, currently intel and gcc use this.
2010-12-16 09:55:35 +00:00
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_WARNINGS
C_WARN_ALL -Wall
C_WARN_ERROR_IMPLICIT_FUNCTION_DECLARATION -Werror=implicit-function-declaration
# System headers sometimes do this, disable for now, was: `-Werror=strict-prototypes`.
C_WARN_STRICT_PROTOTYPES -Wstrict-prototypes
C_WARN_ERROR_RETURN_TYPE -Werror=return-type
C_WARN_ERROR_VLA -Werror=vla
C_WARN_MISSING_PROTOTYPES -Wmissing-prototypes
C_WARN_NO_CHAR_SUBSCRIPTS -Wno-char-subscripts
C_WARN_NO_UNKNOWN_PRAGMAS -Wno-unknown-pragmas
C_WARN_POINTER_ARITH -Wpointer-arith
C_WARN_UNUSED_PARAMETER -Wunused-parameter
C_WARN_WRITE_STRINGS -Wwrite-strings
C_WARN_LOGICAL_OP -Wlogical-op
C_WARN_UNDEF -Wundef
# Needs: `-Wuninitialized`.
C_WARN_INIT_SELF -Winit-self
C_WARN_MISSING_INCLUDE_DIRS -Wmissing-include-dirs
C_WARN_NO_DIV_BY_ZERO -Wno-div-by-zero
C_WARN_TYPE_LIMITS -Wtype-limits
C_WARN_FORMAT_SIGN -Wformat-signedness
C_WARN_RESTRICT -Wrestrict
# Useful but too many false positives and inconvenient to suppress each occurrence.
C_WARN_NO_STRINGOP_OVERREAD -Wno-stringop-overread
C_WARN_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow
# C-only.
C_WARN_NO_NULL -Wnonnull
C_WARN_ABSOLUTE_VALUE -Wabsolute-value
C_WARN_UNINITIALIZED -Wuninitialized
C_WARN_REDUNDANT_DECLS -Wredundant-decls
C_WARN_SHADOW -Wshadow
# Disable because it gives warnings for printf() & friends.
# C_WARN_DOUBLE_PROMOTION "-Wdouble-promotion -Wno-error=double-promotion"
# Use `ATTR_FALLTHROUGH` macro to suppress.
C_WARN_IMPLICIT_FALLTHROUGH -Wimplicit-fallthrough=5
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
OSX: fix compile by conditional unsupported flags
2012-01-01 16:46:08 +00:00
if(NOT APPLE)
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_WARNINGS
C_WARN_NO_ERROR_UNUSED_BUT_SET_VARIABLE -Wno-error=unused-but-set-variable
)
OSX: fix compile by conditional unsupported flags
2012-01-01 16:46:08 +00:00
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_cxx_compiler_flags(
CXX_WARNINGS
CXX_WARN_UNINITIALIZED -Wuninitialized
CXX_WARN_REDUNDANT_DECLS -Wredundant-decls
CXX_WARN_ALL -Wall
CXX_WARN_NO_INVALID_OFFSETOF -Wno-invalid-offsetof
CXX_WARN_NO_SIGN_COMPARE -Wno-sign-compare
CXX_WARN_LOGICAL_OP -Wlogical-op
# Needs: `-Wuninitialized`.
CXX_WARN_INIT_SELF -Winit-self
CXX_WARN_MISSING_INCLUDE_DIRS -Wmissing-include-dirs
CXX_WARN_NO_DIV_BY_ZERO -Wno-div-by-zero
CXX_WARN_TYPE_LIMITS -Wtype-limits
CXX_WARN_ERROR_RETURN_TYPE -Werror=return-type
CXX_WARN_NO_CHAR_SUBSCRIPTS -Wno-char-subscripts
CXX_WARN_NO_UNKNOWN_PRAGMAS -Wno-unknown-pragmas
CXX_WARN_POINTER_ARITH -Wpointer-arith
CXX_WARN_UNUSED_PARAMETER -Wunused-parameter
CXX_WARN_WRITE_STRINGS -Wwrite-strings
CXX_WARN_UNDEF -Wundef
CMake: enable comma-subscript GCC warning
2023-08-17 23:13:41 +10:00
CXX_WARN_COMMA_SUBSCRIPT -Wcomma-subscript
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
CXX_WARN_FORMAT_SIGN -Wformat-signedness
CXX_WARN_RESTRICT -Wrestrict
CXX_WARN_NO_SUGGEST_OVERRIDE -Wno-suggest-override
CXX_WARN_UNINITIALIZED -Wuninitialized
Build: enable mismatched-tags warning for CLANG Disabled for GCC as this causes a crash which isn't practical to workaround, details in code-comments.
2023-12-08 16:22:18 +11:00
# NOTE(@ideasman42): In GCC 13.2.1 on Linux this causes internal compiler errors.
# The crashes can be resolved by disabling the flag per module (but not via pragmas).
# However this also causes a type mix-up FreeStyle (Blender & FreeStyle's `Curve`)
# so it seems to impact GCC's the internal state enough that it's too risky to enable.
# When this is resolved the check can be enabled for fixed GCC versions.
#
# Prevents linking errors with MSVC.
# `CXX_WARN_MISMATCHED_TAGS -Wmismatched-tags`
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
# Useful but too many false positives and inconvenient to suppress each occurrence.
CXX_WARN_NO_STRINGOP_OVERREAD -Wno-stringop-overread
CXX_WARN_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow
# Use `[[fallthrough]]` or `ATTR_FALLTHROUGH` macro to suppress.
CXX_WARN_IMPLICIT_FALLTHROUGH -Wimplicit-fallthrough=5
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: disable some warnings on mac that cause prints in nearly every file, and remove duplicate -Wundef entries.
2012-10-01 16:45:50 +00:00
# causes too many warnings
if(NOT APPLE)
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_cxx_compiler_flags(
CXX_WARNINGS
CXX_WARN_UNDEF -Wundef
CXX_WARN_MISSING_DECLARATIONS -Wmissing-declarations
)
CMake: disable some warnings on mac that cause prints in nearly every file, and remove duplicate -Wundef entries.
2012-10-01 16:45:50 +00:00
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# ---------------------
Cleanup: suppress 'address' warnings for ./extern/glew Also add comments noting why some warnings shouldn't be added to strict-flags.
2022-05-19 10:33:02 +10:00
# Suppress Strict Flags
#
# Exclude the following warnings from this list:
# - `-Wno-address`:
# This can give useful hints that point to bugs/misleading logic.
# - `-Wno-strict-prototypes`:
# No need to support older C-style prototypes.
#
# If code in `./extern/` needs to suppress these flags that can be done on a case-by-case basis.
correct flags for older GCC's which dont suppport -Wno-deprecated-declarations, detect if the flag is supported before use
2011-10-30 04:48:00 +00:00
# flags to undo strict flags
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_REMOVE_STRICT_FLAGS
C_WARN_NO_DEPRECATED_DECLARATIONS -Wno-deprecated-declarations
C_WARN_NO_UNUSED_PARAMETER -Wno-unused-parameter
C_WARN_NO_UNUSED_FUNCTION -Wno-unused-function
C_WARN_NO_TYPE_LIMITS -Wno-type-limits
C_WARN_NO_INT_IN_BOOL_CONTEXT -Wno-int-in-bool-context
C_WARN_NO_FORMAT -Wno-format
C_WARN_NO_SWITCH -Wno-switch
C_WARN_NO_UNUSED_VARIABLE -Wno-unused-variable
C_WARN_NO_UNUSED_VARIABLE -Wno-uninitialized
C_WARN_NO_IMPLICIT_FALLTHROUGH -Wno-implicit-fallthrough
)
add_check_cxx_compiler_flags(
CXX_REMOVE_STRICT_FLAGS
CXX_WARN_NO_CLASS_MEMACCESS -Wno-class-memaccess
CXX_WARN_NO_COMMENT -Wno-comment
CXX_WARN_NO_UNUSED_TYPEDEFS -Wno-unused-local-typedefs
CXX_WARN_NO_UNUSED_VARIABLE -Wno-unused-variable
Fix: Warnings after Ceres update The external libraries did not properly ignore Wreorder for GCC and MSVC. Pull Request: https://projects.blender.org/blender/blender/pulls/136946
2025-04-03 19:13:07 +02:00
CXX_WARN_NO_UNINITIALIZED -Wno-uninitialized
CXX_WARN_NO_REORDER -Wno-reorder
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
OSX: fix compile by conditional unsupported flags
2012-01-01 16:46:08 +00:00
if(NOT APPLE)
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_REMOVE_STRICT_FLAGS
C_WARN_NO_ERROR_UNUSED_BUT_SET_VARIABLE -Wno-error=unused-but-set-variable
)
OSX: fix compile by conditional unsupported flags
2012-01-01 16:46:08 +00:00
endif()
correct flags for older GCC's which dont suppport -Wno-deprecated-declarations, detect if the flag is supported before use
2011-10-30 04:48:00 +00:00
Unbreak build on macOS with AppleClang from recent cleanup Exact an exact match with Clang broke building when the compiler ID was "AppleClang", reverting parts of [0]. [0]: 6549019ae19cecbea524782054dca0e99cb833b8
2024-03-07 19:56:58 +11:00
elseif(CMAKE_C_COMPILER_ID MATCHES "Clang")
# Matches both "Clang" & "AppleClang" on macOS.
minor fixes - new compositor could use uninitialized var - profile conversion could use uninitialized var - set better warnings for clang+cmake. - remove picky warnings from sphinx doc gen shell script.
2012-06-11 12:13:41 +00:00
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_WARNINGS
# Strange, clang complains these are not supported, but then uses them.
C_WARN_ALL -Wall
C_WARN_ERROR_IMPLICIT_FUNCTION_DECLARATION -Werror=implicit-function-declaration
C_WARN_ERROR_RETURN_TYPE -Werror=return-type
C_WARN_NO_AUTOLOGICAL_COMPARE -Wno-tautological-compare
C_WARN_NO_UNKNOWN_PRAGMAS -Wno-unknown-pragmas
C_WARN_NO_CHAR_SUBSCRIPTS -Wno-char-subscripts
C_WARN_STRICT_PROTOTYPES -Wstrict-prototypes
C_WARN_MISSING_PROTOTYPES -Wmissing-prototypes
C_WARN_UNUSED_PARAMETER -Wunused-parameter
C_WARN_UNDEF -Wundef
C_WARN_UNDEF_PREFIX -Wundef-prefix
C_WARN_ERROR_UNGUARDED_AVAILABILITY_NEW -Werror=unguarded-availability-new
)
add_check_cxx_compiler_flags(
CXX_WARNINGS
CXX_WARN_ALL -Wall
# Using C++20 features while having C++17 as the project language isn't allowed by MSVC.
CXX_CXX20_DESIGNATOR -Wc++20-designator
CXX_WARN_NO_AUTOLOGICAL_COMPARE -Wno-tautological-compare
CXX_WARN_NO_UNKNOWN_PRAGMAS -Wno-unknown-pragmas
CXX_WARN_NO_CHAR_SUBSCRIPTS -Wno-char-subscripts
# We get a lot of these, if its a problem a dev needs to look into it.
CXX_WARN_NO_OVERLOADED_VIRTUAL -Wno-overloaded-virtual
CXX_WARN_NO_SIGN_COMPARE -Wno-sign-compare
CXX_WARN_NO_INVALID_OFFSETOF -Wno-invalid-offsetof
# Apple Clang (tested on version 12) doesn't support this flag while LLVM Clang 11 does.
CXX_WARN_NO_SUGGEST_OVERRIDE -Wno-suggest-override
CXX_WARN_UNDEF -Wundef
CXX_WARN_UNDEF_PREFIX -Wundef-prefix
CXX_WARN_UNUSED_PARAMETER -Wunused-parameter
Build: enable mismatched-tags warning for CLANG Disabled for GCC as this causes a crash which isn't practical to workaround, details in code-comments.
2023-12-08 16:22:18 +11:00
# Prevents linking errors with MSVC.
CXX_WARN_MISMATCHED_TAGS -Wmismatched-tags
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
# Gives too many unfixable warnings.
# `C_WARN_UNUSED_MACROS -Wunused-macros`
# `CXX_WARN_UNUSED_MACROS -Wunused-macros`
CXX_WARN_ERROR_UNGUARDED_AVAILABILITY_NEW -Werror=unguarded-availability-new
)
CMake: Windows: suppress Clang-cl warnings Building with clang on windows isn't an officially supported scenario but it's something we'd like to keep working, but as it doesn't see regular use, things tend to bit rot a bit. 0136289cb6 got things back into somewhat working order however the build log came in at a little over 5.5GiB emitting a total of 11.787.294 warnings (827.847 unique), it was getting to the point where printing all warnings, was a rather significant contributor to the total build time. this PR, suppress every single warning out of that build, one could argue that some of these warnings are actually genuine and should be enabled, and dealt with, the thing is, building with clang isn't supported as of now and I honestly lack the time right now to sift though this barrage of data. given MSVC, Clang on mac and GCC on linux currently all build without warnings, having clang on windows match that baseline seems like a reasonable thing to do. I left some notes in cmake flagging the potential cleanup, and added counts of how often each warn occurred (The one off warns are much more likely to lead to a genuine bug fix than the ones that produce a whole lot of noise) so if someone wants to spend some effort they can do so effectively. The suppression is guarded with clang on windows specific guard and should not affect any other platforms. Pull Request: https://projects.blender.org/blender/blender/pulls/121085
2024-04-25 20:32:20 +02:00
if(MSVC_CLANG)
# clang-cl produces an unhealthy ammount of warnings in its default
# configuration as it for reasons unknown decided to enable all
# warnings known to mankind. Resulting in a 5.5GB build log containing
# well over 11 million warnings. The code below disables every single
# one of them indiscriminately. Someone with time on their hands,
# could/should go over these and either fix them or describe why we
# would want to disable the warning. The list below contains both C
# and C++ warnings for all warnings since clang has seemingly no
# easy way to tell if something is a C or C++ specific warning and
# manually auditing every single one of them just isn't in the cards
# right now.
# /W3 is being removed, then added back again, this is because order
# matters for clang and these flags are being placed before the
# CMAKE_[LANGUAGE]_FLAGS which normally contain /W3, so we would
# disable certain warings here only for them to be re-enabled by /W3
# later on.
remove_cc_flag("/W3")
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
CMake: Windows: suppress Clang-cl warnings Building with clang on windows isn't an officially supported scenario but it's something we'd like to keep working, but as it doesn't see regular use, things tend to bit rot a bit. 0136289cb6 got things back into somewhat working order however the build log came in at a little over 5.5GiB emitting a total of 11.787.294 warnings (827.847 unique), it was getting to the point where printing all warnings, was a rather significant contributor to the total build time. this PR, suppress every single warning out of that build, one could argue that some of these warnings are actually genuine and should be enabled, and dealt with, the thing is, building with clang isn't supported as of now and I honestly lack the time right now to sift though this barrage of data. given MSVC, Clang on mac and GCC on linux currently all build without warnings, having clang on windows match that baseline seems like a reasonable thing to do. I left some notes in cmake flagging the potential cleanup, and added counts of how often each warn occurred (The one off warns are much more likely to lead to a genuine bug fix than the ones that produce a whole lot of noise) so if someone wants to spend some effort they can do so effectively. The suppression is guarded with clang on windows specific guard and should not affect any other platforms. Pull Request: https://projects.blender.org/blender/blender/pulls/121085
2024-04-25 20:32:20 +02:00
add_check_c_compiler_flags(
C_WARNINGS
C_WARN_CLANG_CL_W3 /W3
# The number behind each warn is the number of unique warning were
# generated on 2024-04-24 (d2be9cecc28a03ff1f799e8c63f1f9f8eda7cce3)
# especially the ones in the single and low double digits are likely
# genuine problems that can be investigated.
C_WARN_CLANG_CL_C++98_COMPAT -Wno-c++98-compat # 352692
C_WARN_CLANG_CL_OLD_STYLE_CAST -Wno-old-style-cast # 178608
C_WARN_CLANG_CL_UNSAFE_BUFFER_USAGE -Wno-unsafe-buffer-usage # 89032
C_WARN_CLANG_CL_MISSING_PROTOTYPES -Wno-missing-prototypes # 25587
C_WARN_CLANG_CL_SIGN_CONVERSION -Wno-sign-conversion # 20109
C_WARN_CLANG_CL_MISSING_FIELD_INITIALIZERS -Wno-missing-field-initializers # 20060
C_WARN_CLANG_CL_EXTRA_SEMI -Wno-extra-semi # 12513
C_WARN_CLANG_CL_LANGUAGE_EXTENSION_TOKEN -Wno-language-extension-token # 11032
C_WARN_CLANG_CL_IMPLICIT_FLOAT_CONVERSION -Wno-implicit-float-conversion # 11003
C_WARN_CLANG_CL_C++98_COMPAT_PEDANTIC -Wno-c++98-compat-pedantic # 10336
C_WARN_CLANG_CL_IMPLICIT_INT_FLOAT_CONVERSION -Wno-implicit-int-float-conversion # 7354
C_WARN_CLANG_CL_DOUBLE_PROMOTION -Wno-double-promotion # 7350
C_WARN_CLANG_CL_PRE_C++17_COMPAT -Wno-pre-c++17-compat # 7303
C_WARN_CLANG_CL_SHORTEN_64_TO_32 -Wno-shorten-64-to-32 # 7085
C_WARN_CLANG_CL_C++98_COMPAT_LOCAL_TYPE_TEMPLATE_ARGS -Wno-c++98-compat-local-type-template-args # 6906
C_WARN_CLANG_CL_RESERVED_IDENTIFIER -Wno-reserved-identifier # 5886
C_WARN_CLANG_CL_CAST_ALIGN -Wno-cast-align # 5513
C_WARN_CLANG_CL_DOCUMENTATION -Wno-documentation # 5107
C_WARN_CLANG_CL_DISABLED_MACRO_EXPANSION -Wno-disabled-macro-expansion # 4449
C_WARN_CLANG_CL_EXTRA_SEMI_STMT -Wno-extra-semi-stmt # 4349
C_WARN_CLANG_CL_ZERO_AS_NULL_POINTER_CONSTANT -Wno-zero-as-null-pointer-constant # 3209
C_WARN_CLANG_CL_FLOAT_CONVERSION -Wno-float-conversion # 2869
C_WARN_CLANG_CL_RESERVED_MACRO_IDENTIFIER -Wno-reserved-macro-identifier # 2862
C_WARN_CLANG_CL_CAST_FUNCTION_TYPE_STRICT -Wno-cast-function-type-strict # 2663
C_WARN_CLANG_CL_FLOAT_EQUAL -Wno-float-equal # 2153
C_WARN_CLANG_CL_IMPLICIT_INT_CONVERSION -Wno-implicit-int-conversion # 2117
C_WARN_CLANG_CL_SHADOW -Wno-shadow # 2068
C_WARN_CLANG_CL_SHADOW_FIELD_IN_CONSTRUCTOR -Wno-shadow-field-in-constructor # 1829
C_WARN_CLANG_CL_CAST_QUAL -Wno-cast-qual # 1742
C_WARN_CLANG_CL_PRE_C++14_COMPAT -Wno-pre-c++14-compat # 1569
C_WARN_CLANG_CL_GLOBAL_CONSTRUCTORS -Wno-global-constructors # 1402
C_WARN_CLANG_CL_SWITCH_ENUM -Wno-switch-enum # 973
C_WARN_CLANG_CL_EXIT_TIME_DESTRUCTORS -Wno-exit-time-destructors # 940
C_WARN_CLANG_CL_CTAD_MAYBE_UNSUPPORTED -Wno-ctad-maybe-unsupported # 891
C_WARN_CLANG_CL_UNDEFINED_FUNC_TEMPLATE -Wno-undefined-func-template # 863
C_WARN_CLANG_CL_C++98_COMPAT_EXTRA_SEMI -Wno-c++98-compat-extra-semi # 848
C_WARN_CLANG_CL_CAST_FUNCTION_TYPE -Wno-cast-function-type # 807
C_WARN_CLANG_CL_NULLABILITY_EXTENSION -Wno-nullability-extension # 602
C_WARN_CLANG_CL_SHADOW_FIELD -Wno-shadow-field # 585
C_WARN_CLANG_CL_CONDITIONAL_UNINITIALIZED -Wno-conditional-uninitialized # 555
C_WARN_CLANG_CL_UNUSED_PARAMETER -Wno-unused-parameter # 539
C_WARN_CLANG_CL_SUGGEST_DESTRUCTOR_OVERRIDE -Wno-suggest-destructor-override # 356
C_WARN_CLANG_CL_SHADOW_UNCAPTURED_LOCAL -Wno-shadow-uncaptured-local # 355
C_WARN_CLANG_CL_UNUSED_MACROS -Wno-unused-macros # 289
C_WARN_CLANG_CL_COVERED_SWITCH_DEFAULT -Wno-covered-switch-default # 233
C_WARN_CLANG_CL_SIGNED_ENUM_BITFIELD -Wno-signed-enum-bitfield # 229
C_WARN_CLANG_CL_DECLARATION_AFTER_STATEMENT -Wno-declaration-after-statement # 228
C_WARN_CLANG_CL_IMPLICIT_FALLTHROUGH -Wno-implicit-fallthrough # 164
C_WARN_CLANG_CL_NON_VIRTUAL_DTOR -Wno-non-virtual-dtor # 161
C_WARN_CLANG_CL_NESTED_ANON_TYPES -Wno-nested-anon-types # 140
C_WARN_CLANG_CL_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS -Wno-gnu-zero-variadic-macro-arguments # 132
C_WARN_CLANG_CL_UNREACHABLE_CODE_BREAK -Wno-unreachable-code-break # 115
C_WARN_CLANG_CL_INCONSISTENT_MISSING_DESTRUCTOR_OVERRIDE -Wno-inconsistent-missing-destructor-override # 104
C_WARN_CLANG_CL_FORMAT_PEDANTIC -Wno-format-pedantic # 97
C_WARN_CLANG_CL_NONPORTABLE_SYSTEM_INCLUDE_PATH -Wno-nonportable-system-include-path # 95
C_WARN_CLANG_CL_UNDEF -Wno-undef # 94
C_WARN_CLANG_CL_IGNORED_QUALIFIERS -Wno-ignored-qualifiers # 93
C_WARN_CLANG_CL_USED_BUT_MARKED_UNUSED -Wno-used-but-marked-unused # 83
C_WARN_CLANG_CL_HEADER_HYGIENE -Wno-header-hygiene # 79
C_WARN_CLANG_CL_CHAR_SUBSCRIPTS -Wno-char-subscripts # 76
C_WARN_CLANG_CL_UNREACHABLE_CODE_RETURN -Wno-unreachable-code-return # 71
C_WARN_CLANG_CL_UNUSED_TEMPLATE -Wno-unused-template # 66
C_WARN_CLANG_CL_GNU_ANONYMOUS_STRUCT -Wno-gnu-anonymous-struct # 63
C_WARN_CLANG_CL_DEPRECATED_COPY_WITH_USER_PROVIDED_DTOR -Wno-deprecated-copy-with-user-provided-dtor # 62
C_WARN_CLANG_CL_INCONSISTENT_MISSING_OVERRIDE -Wno-inconsistent-missing-override # 54
C_WARN_CLANG_CL_UNREACHABLE_CODE -Wno-unreachable-code # 52
C_WARN_CLANG_CL_DEPRECATED_DYNAMIC_EXCEPTION_SPEC -Wno-deprecated-dynamic-exception-spec # 51
C_WARN_CLANG_CL_BAD_FUNCTION_CAST -Wno-bad-function-cast # 50
C_WARN_CLANG_CL_MICROSOFT_ENUM_VALUE -Wno-microsoft-enum-value # 47
C_WARN_CLANG_CL_DEPRECATED_COPY_WITH_USER_PROVIDED_COPY -Wno-deprecated-copy-with-user-provided-copy # 41
C_WARN_CLANG_CL_ZERO_LENGTH_ARRAY -Wno-zero-length-array # 39
C_WARN_CLANG_CL_UNUSED_FUNCTION -Wno-unused-function # 38
C_WARN_CLANG_CL_PEDANTIC -Wno-pedantic # 38
C_WARN_CLANG_CL_DEPRECATED_COPY_WITH_DTOR -Wno-deprecated-copy-with-dtor # 37
C_WARN_CLANG_CL_DOCUMENTATION_UNKNOWN_COMMAND -Wno-documentation-unknown-command # 34
C_WARN_CLANG_CL_UNDEFINED_REINTERPRET_CAST -Wno-undefined-reinterpret-cast # 33
C_WARN_CLANG_CL_FORMAT_NONLITERAL -Wno-format-nonliteral # 29
C_WARN_CLANG_CL_COMMA -Wno-comma # 27
C_WARN_CLANG_CL_DOCUMENTATION_DEPRECATED_SYNC -Wno-documentation-deprecated-sync # 26
C_WARN_CLANG_CL_SHIFT_SIGN_OVERFLOW -Wno-shift-sign-overflow # 24
C_WARN_CLANG_CL_PRE_C++17_COMPAT_PEDANTIC -Wno-pre-c++17-compat-pedantic # 24
C_WARN_CLANG_CL_C++98_COMPAT_UNNAMED_TYPE_TEMPLATE_ARGS -Wno-c++98-compat-unnamed-type-template-args # 22
C_WARN_CLANG_CL_SIGN_COMPARE -Wno-sign-compare # 21
C_WARN_CLANG_CL_FORMAT -Wno-format # 21
C_WARN_CLANG_CL_C++98_COMPAT_BIND_TO_TEMPORARY_COPY -Wno-c++98-compat-bind-to-temporary-copy # 21
C_WARN_CLANG_CL_ENUM_ENUM_CONVERSION -Wno-enum-enum-conversion # 20
C_WARN_CLANG_CL_ANON_ENUM_ENUM_CONVERSION -Wno-anon-enum-enum-conversion # 14
C_WARN_CLANG_CL_RANGE_LOOP_BIND_REFERENCE -Wno-range-loop-bind-reference # 14
C_WARN_CLANG_CL_ENUM_FLOAT_CONVERSION -Wno-enum-float-conversion # 12
C_WARN_CLANG_CL_KEYWORD_MACRO -Wno-keyword-macro # 10
C_WARN_CLANG_CL_DEPRECATED_COPY -Wno-deprecated-copy # 10
C_WARN_CLANG_CL_UNUSED_MEMBER_FUNCTION -Wno-unused-member-function # 9
C_WARN_CLANG_CL_MISSING_NORETURN -Wno-missing-noreturn # 8
C_WARN_CLANG_CL_MISSING_VARIABLE_DECLARATIONS -Wno-missing-variable-declarations # 8
C_WARN_CLANG_CL_DOCUMENTATION_HTML -Wno-documentation-html # 6
C_WARN_CLANG_CL_GNU_REDECLARED_ENUM -Wno-gnu-redeclared-enum # 6
C_WARN_CLANG_CL_DEPRECATED_DECLARATIONS -Wno-deprecated-declarations # 6
C_WARN_CLANG_CL_OVERLOADED_VIRTUAL -Wno-overloaded-virtual # 5
C_WARN_CLANG_CL_C++98_C++11_COMPAT_BINARY_LITERAL -Wno-c++98-c++11-compat-binary-literal # 4
C_WARN_CLANG_CL_DEPRECATED_REDUNDANT_CONSTEXPR_STATIC_DEF -Wno-deprecated-redundant-constexpr-static-def # 4
C_WARN_CLANG_CL_MISSING_BRACES -Wno-missing-braces # 4
C_WARN_CLANG_CL_C99_EXTENSIONS -Wno-c99-extensions # 4
C_WARN_CLANG_CL_STRICT_PROTOTYPES -Wno-strict-prototypes # 4
C_WARN_CLANG_CL_UNREACHABLE_CODE_LOOP_INCREMENT -Wno-unreachable-code-loop-increment # 4
C_WARN_CLANG_CL_GNU_CASE_RANGE -Wno-gnu-case-range # 4
C_WARN_CLANG_CL_DUPLICATE_ENUM -Wno-duplicate-enum # 3
C_WARN_CLANG_CL_NULL_POINTER_SUBTRACTION -Wno-null-pointer-subtraction # 2
C_WARN_CLANG_CL_DEPRECATED_LITERAL_OPERATOR -Wno-deprecated-literal-operator # 2
C_WARN_CLANG_CL_NEWLINE_EOF -Wno-newline-eof # 2
C_WARN_CLANG_CL_MICROSOFT_CAST -Wno-microsoft-cast # 2
C_WARN_CLANG_CL_DATE_TIME -Wno-date-time # 2
C_WARN_CLANG_CL_DELETE_NON_ABSTRACT_NON_VIRTUAL_DTOR -Wno-delete-non-abstract-non-virtual-dtor # 2
C_WARN_CLANG_CL_UNUSED_PRIVATE_FIELD -Wno-unused-private-field # 2
C_WARN_CLANG_CL_FLEXIBLE_ARRAY_EXTENSIONS -Wno-flexible-array-extensions # 2
C_WARN_CLANG_CL_STRING_CONVERSION -Wno-string-conversion # 2
C_WARN_CLANG_CL_FINAL_DTOR_NON_FINAL_CLASS -Wno-final-dtor-non-final-class # 2
C_WARN_CLANG_CL_MICROSOFT_UNQUALIFIED_FRIEND -Wno-microsoft-unqualified-friend # 2
C_WARN_CLANG_CL_INVALID_NORETURN -Wno-invalid-noreturn # 1
C_WARN_CLANG_CL_INVALID_UTF8 -Wno-invalid-utf8 # 1
C_WARN_CLANG_CL_FOUR_CHAR_CONSTANTS -Wno-four-char-constants # 1
C_WARN_CLANG_CL_PARENTHESES -Wno-parentheses # 1
C_WARN_CLANG_CL_PESSIMIZING_MOVE -Wno-pessimizing-move # 1
C_WARN_CLANG_CL_DEPRECATED_NON_PROTOTYPE -Wno-deprecated-non-prototype # 1
C_WARN_CLANG_CL_BITFIELD_ENUM_CONVERSION -Wno-bitfield-enum-conversion # 1
C_WARN_CLANG_CL_UNUSED_LAMBDA_CAPTURE -Wno-unused-lambda-capture # 1
C_WARN_CLANG_CL_SHADOW_FIELD_IN_CONSTRUCTOR_MODIFIED -Wno-shadow-field-in-constructor-modified # 1
Windows: Enable clang-cl for ARM64 This gets Windows ARM64 to compile with clang-cl, which gives up to 40% performance improvements in certain scenes rendered with cycles, compared to MSVC. This is all tested using LLVM 18.1.8 and a VS2022 `vcvarsall` window. Subsequent PRs with various lib version updates, etc to go in at a later point. Pull Request: https://projects.blender.org/blender/blender/pulls/124182
2024-08-12 16:50:07 +02:00
# And some additional ones that came up when using LLVM 18.1.8 on Windows ARM64
C_WARN_CLANG_CL_SWITCH_DEFAULT -Wno-switch-default
C_WARN_CLANG_CL_NAN_INFINITY_DISABLED -Wno-nan-infinity-disabled
Windows: Enable OpenMP on ARM64, and quiet new noisy warning New versions of LLVM now ship with OpenMP for these devices, so enable accordingly. The disabled warning was causing substantial spam in buildbot logs. Pull Request: https://projects.blender.org/blender/blender/pulls/134583
2025-02-20 11:24:22 +01:00
# And another from 19.1.5
C_WARN_CLANG_CL_PRE_C11_COMPAT -Wno-pre-c11-compat
CMake: Windows: suppress Clang-cl warnings Building with clang on windows isn't an officially supported scenario but it's something we'd like to keep working, but as it doesn't see regular use, things tend to bit rot a bit. 0136289cb6 got things back into somewhat working order however the build log came in at a little over 5.5GiB emitting a total of 11.787.294 warnings (827.847 unique), it was getting to the point where printing all warnings, was a rather significant contributor to the total build time. this PR, suppress every single warning out of that build, one could argue that some of these warnings are actually genuine and should be enabled, and dealt with, the thing is, building with clang isn't supported as of now and I honestly lack the time right now to sift though this barrage of data. given MSVC, Clang on mac and GCC on linux currently all build without warnings, having clang on windows match that baseline seems like a reasonable thing to do. I left some notes in cmake flagging the potential cleanup, and added counts of how often each warn occurred (The one off warns are much more likely to lead to a genuine bug fix than the ones that produce a whole lot of noise) so if someone wants to spend some effort they can do so effectively. The suppression is guarded with clang on windows specific guard and should not affect any other platforms. Pull Request: https://projects.blender.org/blender/blender/pulls/121085
2024-04-25 20:32:20 +02:00
)
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
Cleanup: correct indentation for CMake files, strip trailing space
2025-01-03 13:23:38 +11:00
add_check_cxx_compiler_flags(
CXX_WARNINGS
CMake: Windows: suppress Clang-cl warnings Building with clang on windows isn't an officially supported scenario but it's something we'd like to keep working, but as it doesn't see regular use, things tend to bit rot a bit. 0136289cb6 got things back into somewhat working order however the build log came in at a little over 5.5GiB emitting a total of 11.787.294 warnings (827.847 unique), it was getting to the point where printing all warnings, was a rather significant contributor to the total build time. this PR, suppress every single warning out of that build, one could argue that some of these warnings are actually genuine and should be enabled, and dealt with, the thing is, building with clang isn't supported as of now and I honestly lack the time right now to sift though this barrage of data. given MSVC, Clang on mac and GCC on linux currently all build without warnings, having clang on windows match that baseline seems like a reasonable thing to do. I left some notes in cmake flagging the potential cleanup, and added counts of how often each warn occurred (The one off warns are much more likely to lead to a genuine bug fix than the ones that produce a whole lot of noise) so if someone wants to spend some effort they can do so effectively. The suppression is guarded with clang on windows specific guard and should not affect any other platforms. Pull Request: https://projects.blender.org/blender/blender/pulls/121085
2024-04-25 20:32:20 +02:00
CXX_WARN_CLANG_CL_W3 /W3
CXX_WARN_CLANG_CL_C++98_COMPAT -Wno-c++98-compat # 352692
CXX_WARN_CLANG_CL_OLD_STYLE_CAST -Wno-old-style-cast # 178608
CXX_WARN_CLANG_CL_UNSAFE_BUFFER_USAGE -Wno-unsafe-buffer-usage # 89032
CXX_WARN_CLANG_CL_MISSING_PROTOTYPES -Wno-missing-prototypes # 25587
CXX_WARN_CLANG_CL_SIGN_CONVERSION -Wno-sign-conversion # 20109
CXX_WARN_CLANG_CL_MISSING_FIELD_INITIALIZERS -Wno-missing-field-initializers # 20060
CXX_WARN_CLANG_CL_EXTRA_SEMI -Wno-extra-semi # 12513
CXX_WARN_CLANG_CL_LANGUAGE_EXTENSION_TOKEN -Wno-language-extension-token # 11032
CXX_WARN_CLANG_CL_IMPLICIT_FLOAT_CONVERSION -Wno-implicit-float-conversion # 11003
CXX_WARN_CLANG_CL_C++98_COMPAT_PEDANTIC -Wno-c++98-compat-pedantic # 10336
CXX_WARN_CLANG_CL_IMPLICIT_INT_FLOAT_CONVERSION -Wno-implicit-int-float-conversion # 7354
CXX_WARN_CLANG_CL_DOUBLE_PROMOTION -Wno-double-promotion # 7350
CXX_WARN_CLANG_CL_PRE_C++17_COMPAT -Wno-pre-c++17-compat # 7303
CXX_WARN_CLANG_CL_SHORTEN_64_TO_32 -Wno-shorten-64-to-32 # 7085
CXX_WARN_CLANG_CL_C++98_COMPAT_LOCAL_TYPE_TEMPLATE_ARGS -Wno-c++98-compat-local-type-template-args # 6906
CXX_WARN_CLANG_CL_RESERVED_IDENTIFIER -Wno-reserved-identifier # 5886
CXX_WARN_CLANG_CL_CAST_ALIGN -Wno-cast-align # 5513
CXX_WARN_CLANG_CL_DOCUMENTATION -Wno-documentation # 5107
CXX_WARN_CLANG_CL_DISABLED_MACRO_EXPANSION -Wno-disabled-macro-expansion # 4449
CXX_WARN_CLANG_CL_EXTRA_SEMI_STMT -Wno-extra-semi-stmt # 4349
CXX_WARN_CLANG_CL_ZERO_AS_NULL_POINTER_CONSTANT -Wno-zero-as-null-pointer-constant # 3209
CXX_WARN_CLANG_CL_FLOAT_CONVERSION -Wno-float-conversion # 2869
CXX_WARN_CLANG_CL_RESERVED_MACRO_IDENTIFIER -Wno-reserved-macro-identifier # 2862
CXX_WARN_CLANG_CL_CAST_FUNCTION_TYPE_STRICT -Wno-cast-function-type-strict # 2663
CXX_WARN_CLANG_CL_FLOAT_EQUAL -Wno-float-equal # 2153
CXX_WARN_CLANG_CL_IMPLICIT_INT_CONVERSION -Wno-implicit-int-conversion # 2117
CXX_WARN_CLANG_CL_SHADOW -Wno-shadow # 2068
CXX_WARN_CLANG_CL_SHADOW_FIELD_IN_CONSTRUCTOR -Wno-shadow-field-in-constructor # 1829
CXX_WARN_CLANG_CL_CAST_QUAL -Wno-cast-qual # 1742
CXX_WARN_CLANG_CL_PRE_C++14_COMPAT -Wno-pre-c++14-compat # 1569
CXX_WARN_CLANG_CL_GLOBAL_CONSTRUCTORS -Wno-global-constructors # 1402
CXX_WARN_CLANG_CL_SWITCH_ENUM -Wno-switch-enum # 973
CXX_WARN_CLANG_CL_EXIT_TIME_DESTRUCTORS -Wno-exit-time-destructors # 940
CXX_WARN_CLANG_CL_CTAD_MAYBE_UNSUPPORTED -Wno-ctad-maybe-unsupported # 891
CXX_WARN_CLANG_CL_UNDEFINED_FUNC_TEMPLATE -Wno-undefined-func-template # 863
CXX_WARN_CLANG_CL_C++98_COMPAT_EXTRA_SEMI -Wno-c++98-compat-extra-semi # 848
CXX_WARN_CLANG_CL_CAST_FUNCTION_TYPE -Wno-cast-function-type # 807
CXX_WARN_CLANG_CL_NULLABILITY_EXTENSION -Wno-nullability-extension # 602
CXX_WARN_CLANG_CL_SHADOW_FIELD -Wno-shadow-field # 585
CXX_WARN_CLANG_CL_CONDITIONAL_UNINITIALIZED -Wno-conditional-uninitialized # 555
CXX_WARN_CLANG_CL_UNUSED_PARAMETER -Wno-unused-parameter # 539
CXX_WARN_CLANG_CL_SUGGEST_DESTRUCTOR_OVERRIDE -Wno-suggest-destructor-override # 356
CXX_WARN_CLANG_CL_SHADOW_UNCAPTURED_LOCAL -Wno-shadow-uncaptured-local # 355
CXX_WARN_CLANG_CL_UNUSED_MACROS -Wno-unused-macros # 289
CXX_WARN_CLANG_CL_COVERED_SWITCH_DEFAULT -Wno-covered-switch-default # 233
CXX_WARN_CLANG_CL_SIGNED_ENUM_BITFIELD -Wno-signed-enum-bitfield # 229
CXX_WARN_CLANG_CL_DECLARATION_AFTER_STATEMENT -Wno-declaration-after-statement # 228
CXX_WARN_CLANG_CL_IMPLICIT_FALLTHROUGH -Wno-implicit-fallthrough # 164
CXX_WARN_CLANG_CL_NON_VIRTUAL_DTOR -Wno-non-virtual-dtor # 161
CXX_WARN_CLANG_CL_NESTED_ANON_TYPES -Wno-nested-anon-types # 140
CXX_WARN_CLANG_CL_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS -Wno-gnu-zero-variadic-macro-arguments # 132
CXX_WARN_CLANG_CL_UNREACHABLE_CODE_BREAK -Wno-unreachable-code-break # 115
CXX_WARN_CLANG_CL_INCONSISTENT_MISSING_DESTRUCTOR_OVERRIDE -Wno-inconsistent-missing-destructor-override # 104
CXX_WARN_CLANG_CL_FORMAT_PEDANTIC -Wno-format-pedantic # 97
CXX_WARN_CLANG_CL_NONPORTABLE_SYSTEM_INCLUDE_PATH -Wno-nonportable-system-include-path # 95
CXX_WARN_CLANG_CL_UNDEF -Wno-undef # 94
CXX_WARN_CLANG_CL_IGNORED_QUALIFIERS -Wno-ignored-qualifiers # 93
CXX_WARN_CLANG_CL_USED_BUT_MARKED_UNUSED -Wno-used-but-marked-unused # 83
CXX_WARN_CLANG_CL_HEADER_HYGIENE -Wno-header-hygiene # 79
CXX_WARN_CLANG_CL_CHAR_SUBSCRIPTS -Wno-char-subscripts # 76
CXX_WARN_CLANG_CL_UNREACHABLE_CODE_RETURN -Wno-unreachable-code-return # 71
CXX_WARN_CLANG_CL_UNUSED_TEMPLATE -Wno-unused-template # 66
CXX_WARN_CLANG_CL_GNU_ANONYMOUS_STRUCT -Wno-gnu-anonymous-struct # 63
CXX_WARN_CLANG_CL_DEPRECATED_COPY_WITH_USER_PROVIDED_DTOR -Wno-deprecated-copy-with-user-provided-dtor # 62
CXX_WARN_CLANG_CL_INCONSISTENT_MISSING_OVERRIDE -Wno-inconsistent-missing-override # 54
CXX_WARN_CLANG_CL_UNREACHABLE_CODE -Wno-unreachable-code # 52
CXX_WARN_CLANG_CL_DEPRECATED_DYNAMIC_EXCEPTION_SPEC -Wno-deprecated-dynamic-exception-spec # 51
CXX_WARN_CLANG_CL_BAD_FUNCTION_CAST -Wno-bad-function-cast # 50
CXX_WARN_CLANG_CL_MICROSOFT_ENUM_VALUE -Wno-microsoft-enum-value # 47
CXX_WARN_CLANG_CL_DEPRECATED_COPY_WITH_USER_PROVIDED_COPY -Wno-deprecated-copy-with-user-provided-copy # 41
CXX_WARN_CLANG_CL_ZERO_LENGTH_ARRAY -Wno-zero-length-array # 39
CXX_WARN_CLANG_CL_UNUSED_FUNCTION -Wno-unused-function # 38
CXX_WARN_CLANG_CL_PEDANTIC -Wno-pedantic # 38
CXX_WARN_CLANG_CL_DEPRECATED_COPY_WITH_DTOR -Wno-deprecated-copy-with-dtor # 37
CXX_WARN_CLANG_CL_DOCUMENTATION_UNKNOWN_COMMAND -Wno-documentation-unknown-command # 34
CXX_WARN_CLANG_CL_UNDEFINED_REINTERPRET_CAST -Wno-undefined-reinterpret-cast # 33
CXX_WARN_CLANG_CL_FORMAT_NONLITERAL -Wno-format-nonliteral # 29
CXX_WARN_CLANG_CL_COMMA -Wno-comma # 27
CXX_WARN_CLANG_CL_DOCUMENTATION_DEPRECATED_SYNC -Wno-documentation-deprecated-sync # 26
CXX_WARN_CLANG_CL_SHIFT_SIGN_OVERFLOW -Wno-shift-sign-overflow # 24
CXX_WARN_CLANG_CL_PRE_C++17_COMPAT_PEDANTIC -Wno-pre-c++17-compat-pedantic # 24
CXX_WARN_CLANG_CL_C++98_COMPAT_UNNAMED_TYPE_TEMPLATE_ARGS -Wno-c++98-compat-unnamed-type-template-args # 22
CXX_WARN_CLANG_CL_SIGN_COMPARE -Wno-sign-compare # 21
CXX_WARN_CLANG_CL_FORMAT -Wno-format # 21
CXX_WARN_CLANG_CL_C++98_COMPAT_BIND_TO_TEMPORARY_COPY -Wno-c++98-compat-bind-to-temporary-copy # 21
CXX_WARN_CLANG_CL_ENUM_ENUM_CONVERSION -Wno-enum-enum-conversion # 20
CXX_WARN_CLANG_CL_ANON_ENUM_ENUM_CONVERSION -Wno-anon-enum-enum-conversion # 14
CXX_WARN_CLANG_CL_RANGE_LOOP_BIND_REFERENCE -Wno-range-loop-bind-reference # 14
CXX_WARN_CLANG_CL_ENUM_FLOAT_CONVERSION -Wno-enum-float-conversion # 12
CXX_WARN_CLANG_CL_KEYWORD_MACRO -Wno-keyword-macro # 10
CXX_WARN_CLANG_CL_DEPRECATED_COPY -Wno-deprecated-copy # 10
CXX_WARN_CLANG_CL_UNUSED_MEMBER_FUNCTION -Wno-unused-member-function # 9
CXX_WARN_CLANG_CL_MISSING_NORETURN -Wno-missing-noreturn # 8
CXX_WARN_CLANG_CL_MISSING_VARIABLE_DECLARATIONS -Wno-missing-variable-declarations # 8
CXX_WARN_CLANG_CL_DOCUMENTATION_HTML -Wno-documentation-html # 6
CXX_WARN_CLANG_CL_GNU_REDECLARED_ENUM -Wno-gnu-redeclared-enum # 6
CXX_WARN_CLANG_CL_DEPRECATED_DECLARATIONS -Wno-deprecated-declarations # 6
CXX_WARN_CLANG_CL_OVERLOADED_VIRTUAL -Wno-overloaded-virtual # 5
CXX_WARN_CLANG_CL_C++98_C++11_COMPAT_BINARY_LITERAL -Wno-c++98-c++11-compat-binary-literal # 4
CXX_WARN_CLANG_CL_DEPRECATED_REDUNDANT_CONSTEXPR_STATIC_DEF -Wno-deprecated-redundant-constexpr-static-def # 4
CXX_WARN_CLANG_CL_MISSING_BRACES -Wno-missing-braces # 4
CXX_WARN_CLANG_CL_C99_EXTENSIONS -Wno-c99-extensions # 4
CXX_WARN_CLANG_CL_STRICT_PROTOTYPES -Wno-strict-prototypes # 4
CXX_WARN_CLANG_CL_UNREACHABLE_CODE_LOOP_INCREMENT -Wno-unreachable-code-loop-increment # 4
CXX_WARN_CLANG_CL_GNU_CASE_RANGE -Wno-gnu-case-range # 4
CXX_WARN_CLANG_CL_DUPLICATE_ENUM -Wno-duplicate-enum # 3
CXX_WARN_CLANG_CL_NULL_POINTER_SUBTRACTION -Wno-null-pointer-subtraction # 2
CXX_WARN_CLANG_CL_DEPRECATED_LITERAL_OPERATOR -Wno-deprecated-literal-operator # 2
CXX_WARN_CLANG_CL_NEWLINE_EOF -Wno-newline-eof # 2
CXX_WARN_CLANG_CL_MICROSOFT_CAST -Wno-microsoft-cast # 2
CXX_WARN_CLANG_CL_DATE_TIME -Wno-date-time # 2
CXX_WARN_CLANG_CL_DELETE_NON_ABSTRACT_NON_VIRTUAL_DTOR -Wno-delete-non-abstract-non-virtual-dtor # 2
CXX_WARN_CLANG_CL_UNUSED_PRIVATE_FIELD -Wno-unused-private-field # 2
CXX_WARN_CLANG_CL_FLEXIBLE_ARRAY_EXTENSIONS -Wno-flexible-array-extensions # 2
CXX_WARN_CLANG_CL_STRING_CONVERSION -Wno-string-conversion # 2
CXX_WARN_CLANG_CL_FINAL_DTOR_NON_FINAL_CLASS -Wno-final-dtor-non-final-class # 2
CXX_WARN_CLANG_CL_MICROSOFT_UNQUALIFIED_FRIEND -Wno-microsoft-unqualified-friend # 2
CXX_WARN_CLANG_CL_INVALID_NORETURN -Wno-invalid-noreturn # 1
CXX_WARN_CLANG_CL_INVALID_UTF8 -Wno-invalid-utf8 # 1
CXX_WARN_CLANG_CL_FOUR_CHAR_CONSTANTS -Wno-four-char-constants # 1
CXX_WARN_CLANG_CL_PARENTHESES -Wno-parentheses # 1
CXX_WARN_CLANG_CL_PESSIMIZING_MOVE -Wno-pessimizing-move # 1
CXX_WARN_CLANG_CL_DEPRECATED_NON_PROTOTYPE -Wno-deprecated-non-prototype # 1
CXX_WARN_CLANG_CL_BITFIELD_ENUM_CONVERSION -Wno-bitfield-enum-conversion # 1
CXX_WARN_CLANG_CL_UNUSED_LAMBDA_CAPTURE -Wno-unused-lambda-capture # 1
CXX_WARN_CLANG_CL_SHADOW_FIELD_IN_CONSTRUCTOR_MODIFIED -Wno-shadow-field-in-constructor-modified # 1
Windows: Enable clang-cl for ARM64 This gets Windows ARM64 to compile with clang-cl, which gives up to 40% performance improvements in certain scenes rendered with cycles, compared to MSVC. This is all tested using LLVM 18.1.8 and a VS2022 `vcvarsall` window. Subsequent PRs with various lib version updates, etc to go in at a later point. Pull Request: https://projects.blender.org/blender/blender/pulls/124182
2024-08-12 16:50:07 +02:00
# And some additional ones that came up when using LLVM 18.1.8 on Windows ARM64
CXX_WARN_CLANG_CL_SWITCH_DEFAULT -Wno-switch-default
CXX_WARN_CLANG_CL_NAN_INFINITY_DISABLED -Wno-nan-infinity-disabled
Windows: Enable OpenMP on ARM64, and quiet new noisy warning New versions of LLVM now ship with OpenMP for these devices, so enable accordingly. The disabled warning was causing substantial spam in buildbot logs. Pull Request: https://projects.blender.org/blender/blender/pulls/134583
2025-02-20 11:24:22 +01:00
# And another from 19.1.5
CXX_WARN_CLANG_CL_PRE_C11_COMPAT -Wno-pre-c11-compat
CMake: Windows: suppress Clang-cl warnings Building with clang on windows isn't an officially supported scenario but it's something we'd like to keep working, but as it doesn't see regular use, things tend to bit rot a bit. 0136289cb6 got things back into somewhat working order however the build log came in at a little over 5.5GiB emitting a total of 11.787.294 warnings (827.847 unique), it was getting to the point where printing all warnings, was a rather significant contributor to the total build time. this PR, suppress every single warning out of that build, one could argue that some of these warnings are actually genuine and should be enabled, and dealt with, the thing is, building with clang isn't supported as of now and I honestly lack the time right now to sift though this barrage of data. given MSVC, Clang on mac and GCC on linux currently all build without warnings, having clang on windows match that baseline seems like a reasonable thing to do. I left some notes in cmake flagging the potential cleanup, and added counts of how often each warn occurred (The one off warns are much more likely to lead to a genuine bug fix than the ones that produce a whole lot of noise) so if someone wants to spend some effort they can do so effectively. The suppression is guarded with clang on windows specific guard and should not affect any other platforms. Pull Request: https://projects.blender.org/blender/blender/pulls/121085
2024-04-25 20:32:20 +02:00
)
endif()
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
Treat -Wunguarded-availability-new as an error This makes it so access to macOS SDK from newer versions than our deployment target can be detected on a buildbot via failed build. Pull Request: https://projects.blender.org/blender/blender/pulls/105595
2023-03-17 10:45:03 +01:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# ---------------------
Cleanup: suppress 'address' warnings for ./extern/glew Also add comments noting why some warnings shouldn't be added to strict-flags.
2022-05-19 10:33:02 +10:00
# Suppress Strict Flags
tweaks to clang so blender can build with -Werror
2013-03-14 07:25:54 +00:00
# flags to undo strict flags
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_REMOVE_STRICT_FLAGS
C_WARN_NO_UNUSED_PARAMETER -Wno-unused-parameter
C_WARN_NO_UNUSED_VARIABLE -Wno-unused-variable
C_WARN_NO_UNUSED_MACROS -Wno-unused-macros
C_WARN_NO_MISLEADING_INDENTATION -Wno-misleading-indentation
C_WARN_NO_MISSING_VARIABLE_DECLARATIONS -Wno-missing-variable-declarations
C_WARN_NO_INCOMPAT_PTR_DISCARD_QUAL -Wno-incompatible-pointer-types-discards-qualifiers
C_WARN_NO_UNUSED_FUNCTION -Wno-unused-function
C_WARN_NO_INT_TO_VOID_POINTER_CAST -Wno-int-to-void-pointer-cast
C_WARN_NO_MISSING_PROTOTYPES -Wno-missing-prototypes
C_WARN_NO_DUPLICATE_ENUM -Wno-duplicate-enum
C_WARN_NO_UNDEF -Wno-undef
C_WARN_NO_MISSING_NORETURN -Wno-missing-noreturn
C_WARN_NO_UNUSED_BUT_SET_VARIABLE -Wno-unused-but-set-variable
C_WARN_NO_DEPRECATED_DECLARATIONS -Wno-deprecated-declarations
C_WARN_NO_STRICT_PROTOTYPES -Wno-strict-prototypes
C_WARN_NO_BITWISE_INSTEAD_OF_LOGICAL -Wno-bitwise-instead-of-logical
C_WARN_NO_IMPLICIT_CONST_INT_FLOAT_CONVERSION -Wno-implicit-const-int-float-conversion
Cleanup: Suppress strict compiler warning for external code The new Clang which came with XCode 15 introduced the new warning: -Wsingle-bit-bitfield-constant-conversion. It is a bit too noisy in the Bullet code. Since the warning is in the code which we do not maintain suppress it similar to other similar warnings. Pull Request: https://projects.blender.org/blender/blender/pulls/113136
2023-10-02 09:56:44 +02:00
C_WARN_NO_SINGLE_BIT_BITFIELD_CONSTANT_CONVERSION -Wno-single-bit-bitfield-constant-conversion
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
)
add_check_cxx_compiler_flags(
CXX_REMOVE_STRICT_FLAGS
CXX_WARN_NO_UNUSED_PARAMETER -Wno-unused-parameter
CXX_WARN_NO_UNUSED_PRIVATE_FIELD -Wno-unused-private-field
CXX_WARN_NO_CXX11_NARROWING -Wno-c++11-narrowing
CXX_WARN_NO_NON_VIRTUAL_DTOR -Wno-non-virtual-dtor
CXX_WARN_NO_UNUSED_MACROS -Wno-unused-macros
CXX_WARN_NO_UNUSED_VARIABLE -Wno-unused-variable
CXX_WARN_NO_REORDER -Wno-reorder
CXX_WARN_NO_COMMENT -Wno-comment
CXX_WARN_NO_UNUSED_TYPEDEFS -Wno-unused-local-typedefs
CXX_WARN_NO_UNDEFINED_VAR_TEMPLATE -Wno-undefined-var-template
CXX_WARN_NO_INSTANTIATION_AFTER_SPECIALIZATION -Wno-instantiation-after-specialization
CXX_WARN_NO_MISLEADING_INDENTATION -Wno-misleading-indentation
CXX_WARN_NO_BITWISE_INSTEAD_OF_LOGICAL -Wno-bitwise-instead-of-logical
CXX_WARN_NO_IMPLICIT_CONST_INT_FLOAT_CONVERSION -Wno-implicit-const-int-float-conversion
CXX_WARN_NO_UNDEF -Wno-undef
CXX_WARN_NO_UNDEF_PREFIX -Wno-undef-prefix
Fix strict warnings in extern/ after Audaspace update Done for Clang compiler. GCC might need the same fix, but would need to be tested separately.
2025-04-18 15:12:23 +02:00
CXX_WARN_NO_INCONSISTENT_MISSING_OVERRIDE -Wno-inconsistent-missing-override
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
)
clang/cmake - quiet warnings for external libs and reference moto as a system include.
2013-07-15 08:26:16 +00:00
Cleanup: use STREQUAL instead of MATCHES for exact comparisons MATCHES takes a REGEX and searches the input for a match, this isn't necessary for CMAKE_SYSTEM_PROCESSOR & CMAKE_*_COMPILER_ID.
2024-03-07 17:56:41 +11:00
elseif(CMAKE_C_COMPILER_ID STREQUAL "Intel")
CMake now tests warnings are supported, GCC 4.0 wasn't working because of unsupported warnings. this can work for other compilers too, currently intel and gcc use this.
2010-12-16 09:55:35 +00:00
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_WARNINGS
C_WARN_ALL -Wall
C_WARN_POINTER_ARITH -Wpointer-arith
C_WARN_NO_UNKNOWN_PRAGMAS -Wno-unknown-pragmas
)
CMake now tests warnings are supported, GCC 4.0 wasn't working because of unsupported warnings. this can work for other compilers too, currently intel and gcc use this.
2010-12-16 09:55:35 +00:00
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_cxx_compiler_flags(
CXX_WARNINGS
CMake now tests warnings are supported, GCC 4.0 wasn't working because of unsupported warnings. this can work for other compilers too, currently intel and gcc use this.
2010-12-16 09:55:35 +00:00
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
CXX_WARN_ALL -Wall
CXX_WARN_NO_INVALID_OFFSETOF -Wno-invalid-offsetof
CXX_WARN_NO_SIGN_COMPARE -Wno-sign-compare
)
# Disable numbered, false positives.
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND C_WARNINGS " -wd188,186,144,913,556,858,597,177,1292,167,279,592,94,2722,3199")
string(APPEND CXX_WARNINGS " -wd188,186,144,913,556,858,597,177,1292,167,279,592,94,2722,3199")
Cleanup: use STREQUAL instead of MATCHES for exact comparisons MATCHES takes a REGEX and searches the input for a match, this isn't necessary for CMAKE_SYSTEM_PROCESSOR & CMAKE_*_COMPILER_ID.
2024-03-07 17:56:41 +11:00
elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
Cleanup: spelling in comments (make check_spelling_*)
2025-04-12 19:21:41 +10:00
# Most MSVC warnings are C & C++.
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
set(_WARNINGS
# warning level:
"/W3"
"/w34062" # switch statement contains 'default' but no 'case' labels
MSVC: lower C4100 warning level from 4 to 3 The C4100 warning is related to unused formal parameters in functions. Enabling it better aligns with "-Wunused-parameter" option in other compilers. While suppressing it with `__pragma(warning(suppress:4100))` is not the same as using `__attribute__((__unused__))` in GCC or Clang, it is still preferable to use it over completely hiding the warning. This ensures consistent warning behavior across compilers and improves code quality by addressing unused function parameters. (Note that some warnings in Windows-specific code have already been silenced in 7fcb262dfd2f48a73f9cf794944ff677c36e3783) Pull Request: https://projects.blender.org/blender/blender/pulls/105534
2023-03-09 16:05:48 +01:00
"/w34100" # 'identifier' : unreferenced formal parameter
MSVC: add C4115 and C4189 warnings. This matches the warnings of the other compilers commonly used in Blender.
2019-03-22 16:15:46 -03:00
"/w34115" # 'type' : named type definition in parentheses
MSVC: Set the warning C4189 from level 4 to level 3 This is a useful warning and there is an equivalent used in `GNUC` and `clang` compilers. Reviewed on IRC by @brecht and @LazyDodo
2018-08-29 13:08:00 -03:00
"/w34189" # local variable is initialized but not referenced
Cleanup: remove workarounds and version checks for unsupported compilers Match minimum supported versions from the WIKI [0] by raising them to: - GCC 9.3.1 - CLANG 8.0 - MVCS 2019 (16.9.16 / 1928) Details: - Add CMake checks that ensure supported compiler versions early on. - Previously GCC per-processor version checks served to exclude `__clang__`, in some cases this has been replaced by explicitly excluding `__clang__`. This was needed as CLANG treated some of these flags differently to GCC, causing the build to fail. - Remove USE_APPLE_OMP_FIX GCC-4.2 OpenMP workaround. - Remove linking error workaround for old MSVC versions. [0]: https://wiki.blender.org/wiki/Building_Blender Reviewed by: brecht, LazyDodo Ref D16068
2022-09-26 12:26:48 +10:00
# see https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/c5038?view=vs-2017
"/w35038" # order of initialization in c++ constructors
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
# disable:
"/wd4018" # signed/unsigned mismatch
CMake: disable warning 4146 This is warning on noisy (false positives).
2015-12-21 14:54:36 +11:00
"/wd4146" # unary minus operator applied to unsigned type, result still unsigned
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
"/wd4065" # switch statement contains 'default' but no 'case' labels
"/wd4127" # conditional expression is constant
"/wd4181" # qualifier applied to reference type; ignored
"/wd4200" # zero-sized array in struct/union
"/wd4244" # conversion from 'type1' to 'type2', possible loss of data
"/wd4267" # conversion from 'size_t' to 'type', possible loss of data
"/wd4305" # truncation from 'type1' to 'type2'
"/wd4800" # forcing value to bool 'true' or 'false'
Cleanup: trailing space in CMake files
2018-06-10 08:12:13 +02:00
"/wd4828" # The file contains a character that is illegal
CMake: Repress deprecation warnings with MSVC.
2018-09-25 11:05:01 -06:00
"/wd4996" # identifier was declared deprecated
cmake/msvc: Repress MSVC template warning C4661 Draco emits about 60 of these, consulted with brecht before repressing them.
2019-05-26 16:13:31 -06:00
"/wd4661" # no suitable definition provided for explicit template instantiation request
BLI: use no_unique_address attribute Even though the `no_unique_address` attribute has only been standardized in C++20, compilers seem to support it with C++17 already. This attribute allows reducing the memory footprint of structs which have empty types as data members (usually that is an allocator or inline buffer in Blender). Previously, one had to use the empty base optimization to achieve the same effect, which requires a lot of boilerplate code. The types that benefit from this the most are `Vector` and `Array`, which usually become 8 bytes smaller. All types which use these core data structures get smaller as well of course. Differential Revision: https://developer.blender.org/D14993
2022-05-25 16:28:07 +02:00
"/wd4848" # 'no_unique_address' is a vendor extension in C++17
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
# errors:
"/we4013" # 'function' undefined; assuming extern returning int
CMake: move MSVC warnings to central location
2017-09-28 12:59:28 +10:00
"/we4133" # incompatible pointer types
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
"/we4431" # missing type specifier - int assumed
MSVC: promote C4033 to an error C4033 'function' must return a value is a MSVC level-1 warning, clang and GCC treat this as an error however, this change promotes it to an error as well for MSVC to mimic the GCC behaviour.
2022-09-28 08:32:56 -06:00
"/we4033" # 'function' must return a value
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
Cmake cleanup Move compiler warnings for msvc to common compilerwarnings.
2014-11-08 21:17:04 +01:00
string(REPLACE ";" " " _WARNINGS "${_WARNINGS}")
set(C_WARNINGS "${_WARNINGS}")
set(CXX_WARNINGS "${_WARNINGS}")
unset(_WARNINGS)
- fixed remaining unused warnings. - omit render code from this warning (cmake only), until render branch is merged. - moved -Wunused-parameter warning to apply to all C code in blender (not just ./source/blender), (cmake only).
2010-10-17 06:38:56 +00:00
endif()
Build: fix Xcode warnings related to integer conversion Xcode enables additional warning flags by default. Disable some to match command line build and other platforms more closely. Ref #111193
2023-08-17 15:54:04 +02:00
# Xcode enables additional warning flags by default. Disable some to match
# command line build and other platforms more closely.
if(XCODE)
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_64_TO_32_BIT_CONVERSION NO)
endif()
print an error message if Python.h can't be found for cmake and scons since its such a common problem.
2011-07-16 06:55:45 +00:00
# ensure python header is found since detection can fail, this could happen
# with _any_ library but since we used a fixed python version this tends to
# be most problematic.
if(WITH_PYTHON)
if(NOT EXISTS "${PYTHON_INCLUDE_DIR}/Python.h")
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
message(
FATAL_ERROR
Cleanup: cmake, indentation, line length
2016-05-18 11:58:08 +10:00
"Missing: \"${PYTHON_INCLUDE_DIR}/Python.h\",\n"
"Set the cache entry 'PYTHON_INCLUDE_DIR' to point "
"to a valid python include path. Containing "
"Python.h for python version \"${PYTHON_VERSION}\""
)
print an error message if Python.h can't be found for cmake and scons since its such a common problem.
2011-07-16 06:55:45 +00:00
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
Python: on macOS, stop requiring framework for building bpy module Build against Python from precompiled libraries by default, instead of requiring framework from python.org package install. The resulting bpy module can still be used with any Python install of the same version. Use the same CMake find module as Linux. This simplifies code, and makes it possible to manually set PYTHON_* variables in CMake configuration. Remove WITH_PYTHON_FRAMEWORK option for regular Blender build, as this doesn't work well due to missing required Python packages. Advanced users can still set PYTHON_ROOT_DIR=/Library/Frameworks/Python.framework/Versions/3.10 for the same result.
2022-09-09 03:12:56 +02:00
if(WIN32)
# Always use numpy bundled in precompiled libs.
Fix several issues with handling of numpy in CMake. 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
2020-12-14 16:40:00 +01:00
elseif((WITH_PYTHON_INSTALL AND WITH_PYTHON_INSTALL_NUMPY) OR WITH_PYTHON_NUMPY)
Audaspace: Moving audaspace 1.3 into extern. Deleting the old internal audaspace. Major changes from there are: - The whole library was refactored to use C++11. - Many stability and performance improvements. - Major Python API refactor: - Most requested: Play self generated sounds using numpy arrays. - For games: Sound list, random sounds and dynamic music. - Writing sounds to files. - Sequencing API. - Opening sound devices, eg. Jack. - Ability to choose different OpenAL devices in the user settings.
2017-08-18 08:24:12 +02:00
if(("${PYTHON_NUMPY_PATH}" STREQUAL "") OR (${PYTHON_NUMPY_PATH} MATCHES NOTFOUND))
CMake: detect numpy with Python 3.13 Resolves #137635.
2025-04-17 17:32:48 +10:00
set(_numpy_include "_core/include")
if(PYTHON_VERSION VERSION_LESS "3.13")
set(_numpy_include "core/include")
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
endif()
CMake: detect numpy with Python 3.13 Resolves #137635.
2025-04-17 17:32:48 +10:00
find_python_package(numpy "${_numpy_include}")
unset(_numpy_include)
Cleanup: CMake indentation & wrap long lines
2025-05-20 11:20:09 +10:00
endif()
WITH_PYTHON_INSTALL_NUMPY option for unix/cmake, just copies from site-packages.
2012-04-30 09:38:32 +00:00
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
Build system: add cmake option to install requests
2014-03-05 05:39:53 +11:00
if(WIN32 OR APPLE)
Python: on macOS, stop requiring framework for building bpy module Build against Python from precompiled libraries by default, instead of requiring framework from python.org package install. The resulting bpy module can still be used with any Python install of the same version. Use the same CMake find module as Linux. This simplifies code, and makes it possible to manually set PYTHON_* variables in CMake configuration. Remove WITH_PYTHON_FRAMEWORK option for regular Blender build, as this doesn't work well due to missing required Python packages. Advanced users can still set PYTHON_ROOT_DIR=/Library/Frameworks/Python.framework/Versions/3.10 for the same result.
2022-09-09 03:12:56 +02:00
# Always copy from precompiled libs.
Build system: add cmake option to install requests
2014-03-05 05:39:53 +11:00
elseif(WITH_PYTHON_INSTALL_REQUESTS)
Fix several issues with handling of numpy in CMake. 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
2020-12-14 16:40:00 +01:00
find_python_package(requests "")
Build system: add cmake option to install requests
2014-03-05 05:39:53 +11:00
endif()
Deps: Python, bundle zstandard package This package allows Python scripts to handle compressed blend files (see rB2ea66af742bc). This is for example needed by Blender Asset Tracer to send files to a Flamenco render farm. This change includes a new `WITH_PYTHON_INSTALL_ZSTANDARD` build-time option, to control whether to actually install the package. For this the already-existing approach for Requests was copied. Reviewed By: LazyDodo, mont29, brecht Differential Revision: https://developer.blender.org/D12777
2021-10-21 13:45:37 +02:00
if(WIN32 OR APPLE)
Python: on macOS, stop requiring framework for building bpy module Build against Python from precompiled libraries by default, instead of requiring framework from python.org package install. The resulting bpy module can still be used with any Python install of the same version. Use the same CMake find module as Linux. This simplifies code, and makes it possible to manually set PYTHON_* variables in CMake configuration. Remove WITH_PYTHON_FRAMEWORK option for regular Blender build, as this doesn't work well due to missing required Python packages. Advanced users can still set PYTHON_ROOT_DIR=/Library/Frameworks/Python.framework/Versions/3.10 for the same result.
2022-09-09 03:12:56 +02:00
# Always copy from precompiled libs.
Deps: Python, bundle zstandard package This package allows Python scripts to handle compressed blend files (see rB2ea66af742bc). This is for example needed by Blender Asset Tracer to send files to a Flamenco render farm. This change includes a new `WITH_PYTHON_INSTALL_ZSTANDARD` build-time option, to control whether to actually install the package. For this the already-existing approach for Requests was copied. Reviewed By: LazyDodo, mont29, brecht Differential Revision: https://developer.blender.org/D12777
2021-10-21 13:45:37 +02:00
elseif(WITH_PYTHON_INSTALL_ZSTANDARD)
find_python_package(zstandard "")
endif()
print an error message if Python.h can't be found for cmake and scons since its such a common problem.
2011-07-16 06:55:45 +00:00
endif()
CMake: Have CMake Control the C++ version. We were manually setting the compiler flags for C++17 support for this previously. CMake can do this for us in a uniform way without having to worry about compiler specifics. Setting these flags manually somehow brought out some unwanted behaviour (CMake switching back to C++14) in the nightly CMake builds. Unsure if that's a CMake bug or planned new behaviour for future version, but best to play it safe. These flags are supported since CMake 3.1 so should not break anything. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D11891
2021-07-14 15:17:02 -06:00
# Select C++17 as the standard for C++ projects.
set(CMAKE_CXX_STANDARD 17)
# If C++17 is not available, downgrading to an earlier standard is NOT OK.
set(CMAKE_CXX_STANDARD_REQUIRED ON)
Cleanup: fix typos in comments and docs Contributed by luzpaz. Differential Revision: https://developer.blender.org/D13264
2021-11-19 12:44:27 +01:00
# Do not enable compiler specific language extensions.
CMake: Have CMake Control the C++ version. We were manually setting the compiler flags for C++17 support for this previously. CMake can do this for us in a uniform way without having to worry about compiler specifics. Setting these flags manually somehow brought out some unwanted behaviour (CMake switching back to C++14) in the nightly CMake builds. Unsure if that's a CMake bug or planned new behaviour for future version, but best to play it safe. These flags are supported since CMake 3.1 so should not break anything. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D11891
2021-07-14 15:17:02 -06:00
set(CMAKE_CXX_EXTENSIONS OFF)
CMake: check GNU compiler before using extension Minor edit, don't assume non-msvc compilers are gcc/gnu compatible.
2015-11-23 08:31:29 +11:00
# Visual Studio has all standards it supports available by default
Windows: Add support for building with clang. This commit contains the minimum to make clang build/work with blender, asan and ninja build support is forthcoming Things to note: 1) Builds and runs, and is able to pass all tests (except for the freestyle_stroke_material.blend test which was broken at that time for all platforms by the looks of it) 2) It's slightly faster than msvc when using cycles. (time in seconds, on an i7-3370) victor_cpu msvc:3099.51 clang:2796.43 pavillon_barcelona_cpu msvc:1872.05 clang:1827.72 koro_cpu msvc:1097.58 clang:1006.51 fishy_cat_cpu msvc:815.37 clang:722.2 classroom_cpu msvc:1705.39 clang:1575.43 bmw27_cpu msvc:552.38 clang:561.53 barbershop_interior_cpu msvc:2134.93 clang:1922.33 3) clang on windows uses a drop in replacement for the Microsoft cl.exe (takes some of the Microsoft parameters, but not all, and takes some of the clang parameters but not all) and uses ms headers + libraries + linker, so you still need visual studio installed and will use our existing vc14 svn libs. 4) X64 only currently, X86 builds but crashes on startup. 5) Tested with llvm/clang 6.0.0 6) Requires visual studio integration, available at https://github.com/LazyDodo/llvm-vs2017-integration 7) The Microsoft compiler spawns a few copies of cl in parallel to get faster build times, clang doesn't, so the build time is 3-4x slower than with msvc. 8) No openmp support yet. Have not looked at this much, the binary distribution of clang doesn't seem to include it on windows. 9) No ASAN support yet, some of the sanitizers can be made to work, but it was decided to leave support out of this commit. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D3304
2018-05-28 14:34:47 -06:00
# Clang on windows copies this behavior and does not support these switches
Cleanup: CMake indentation
2025-01-06 12:45:49 +11:00
if(CMAKE_COMPILER_IS_GNUCC OR
(CMAKE_C_COMPILER_ID MATCHES "Clang" AND (NOT MSVC)) OR
(CMAKE_C_COMPILER_ID STREQUAL "Intel"))
CMake: Default to C11 for Clang and GCC The option WITH_C11 is gone, and C++ is defaulting to C++11 now, so guess it's fine to assume we need C11 now. This is technically what we use anyway, with all the re-definitions of structs (like when we typedef anonymous struct in a header file first, and them define it to a proper structure in implementation file).
2018-09-28 10:06:59 +02:00
# Use C11 + GNU extensions, works with GCC, Clang, ICC
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND CMAKE_C_FLAGS " -std=gnu11")
C99 is now the C standard for all our C code. The main new feature is mixed variable declarations and code, which can help reduce uninitialized variables or accidental variable reuse. Due to incomplete C99 support in VS 2013, variable length arrays are not supported, BLI_array_alloca must still be used. The header <tgmath.h> is also not supported. Differential Revision: https://developer.blender.org/D1631
2015-11-22 17:12:54 +01:00
endif()
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
if(WITH_COMPILER_SHORT_FILE_MACRO)
# Use '-fmacro-prefix-map' for Clang and GCC (MSVC doesn't support this).
Cleanup: quiet uninitialized warnings
2023-07-29 13:47:57 +10:00
set(C_PREFIX_MAP_FLAGS "")
set(CXX_PREFIX_MAP_FLAGS "")
CMake: refactor flag checking function to take multiple argument pairs Many calls to add_check_c_compiler_flag add_check_cxx_compiler_flag resulted in over long lines & visual noise. Replace with a function that takes multiple (cache_var flag) pairs to reduce duplication.
2023-08-10 11:28:22 +10:00
add_check_c_compiler_flags(
C_PREFIX_MAP_FLAGS
C_MACRO_PREFIX_MAP -fmacro-prefix-map=foo=bar
)
add_check_cxx_compiler_flags(
CXX_PREFIX_MAP_FLAGS
CXX_MACRO_PREFIX_MAP -fmacro-prefix-map=foo=bar
)
Use compiler check for -fmacro-prefix-map 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
2020-11-04 21:00:29 +05:30
if(C_MACRO_PREFIX_MAP AND CXX_MACRO_PREFIX_MAP)
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
if(APPLE)
if(XCODE AND ${XCODE_VERSION} VERSION_LESS 12.0)
Cleanup: correct indentation for CMake files, strip trailing space
2025-01-03 13:23:38 +11:00
# Developers may have say LLVM Clang-10.0.1 toolchain (which supports the flag)
# with Xcode-11 (the Clang of which doesn't support the flag).
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
message(
WARNING
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
"-fmacro-prefix-map flag is NOT supported by Clang shipped with Xcode-${XCODE_VERSION}."
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
" Some Xcode functionality in Product menu may not work. "
"Disabling WITH_COMPILER_SHORT_FILE_MACRO."
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
)
set(WITH_COMPILER_SHORT_FILE_MACRO OFF)
endif()
endif()
if(WITH_COMPILER_SHORT_FILE_MACRO)
CMake: use path_ensure_trailing_slash for fmacro-prefix-map Use the native system slash so this can work on windows.
2020-11-04 15:59:59 +11:00
path_ensure_trailing_slash(_src_dir "${CMAKE_SOURCE_DIR}")
path_ensure_trailing_slash(_bin_dir "${CMAKE_BINARY_DIR}")
CMake: remove -fmacro-prefix-map from build-info Quotes caused build-info to fail, remove these flags since they're not necessary.
2020-11-04 18:38:49 +11:00
# Keep this variable so it can be stripped from build-info.
set(PLATFORM_CFLAGS_FMACRO_PREFIX_MAP
"-fmacro-prefix-map=\"${_src_dir}\"=\"\" -fmacro-prefix-map=\"${_bin_dir}\"=\"\"")
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND PLATFORM_CFLAGS " ${PLATFORM_CFLAGS_FMACRO_PREFIX_MAP}")
CMake: use path_ensure_trailing_slash for fmacro-prefix-map Use the native system slash so this can work on windows.
2020-11-04 15:59:59 +11:00
unset(_src_dir)
unset(_bin_dir)
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
endif()
else()
Cleanup: cmake line length, wrapping
2022-09-09 11:52:14 +10:00
message(
WARNING
Use compiler check for -fmacro-prefix-map 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
2020-11-04 21:00:29 +05:30
"-fmacro-prefix-map flag is NOT supported by C/C++ compiler."
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
" Disabling WITH_COMPILER_SHORT_FILE_MACRO."
)
set(WITH_COMPILER_SHORT_FILE_MACRO OFF)
endif()
Cleanup: quiet uninitialized warnings
2023-07-29 13:47:57 +10:00
unset(C_PREFIX_MAP_FLAGS)
unset(CXX_PREFIX_MAP_FLAGS)
Clang/GCC: use relative path in __FILE__ macro 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
2020-11-02 15:10:10 +05:30
endif()
switch order cmake includes warning flags so its possible to disable them
2012-10-20 13:08:51 +00:00
# Include warnings first, so its possible to disable them with user defined flags
# eg: -Wno-uninitialized
set(CMAKE_C_FLAGS "${C_WARNINGS} ${CMAKE_C_FLAGS} ${PLATFORM_CFLAGS}")
set(CMAKE_CXX_FLAGS "${CXX_WARNINGS} ${CMAKE_CXX_FLAGS} ${PLATFORM_CFLAGS}")
Merge from trunk -r 22040:23000.
2009-10-19 16:20:12 +00:00
Cleanup: spelling
2017-04-27 21:40:18 +10:00
# defined above, platform specific but shared names
cmake: set python, llvm and osl libs as advanced.
2013-08-28 04:32:39 +00:00
mark_as_advanced(
CYCLES_OSL
OSL_LIB_EXEC
OSL_COMPILER
OSL_LIB_COMP
OSL_LIB_QUERY
Cycles: Synchronize changes with standalone repository This changes were done in original commit of the standalone Cycles repository and needed here for easier patch synchronization.
2014-12-29 14:48:21 +05:00
OSL_INCLUDE_DIR
cmake: set python, llvm and osl libs as advanced.
2013-08-28 04:32:39 +00:00
)
mark_as_advanced(
LLVM_CONFIG
CMake: rename LLVM_DIRECTORY -> LLVM_ROOT_DIR Matching convention with all other libs
2015-03-05 15:36:22 +11:00
LLVM_ROOT_DIR
cmake: set python, llvm and osl libs as advanced.
2013-08-28 04:32:39 +00:00
LLVM_LIBRARY
LLVM_VERSION
)
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -------------------------------------------------------------------------------
Experimental option to build blender as a python module, rather then blender embedding python. CMake build option WITH_PYTHON_MODULE, will build ./bin/bpy.so This allows 'bpy' to be imported from python or other applications/IDE's which embed python, eg: python -c "import bpy ; bpy.ops.render.render(write_still=True)" This runs in background mode and has similar restrictions to running a script: blender --background --python test.py TODO: - install to site-packages with blender scripts - add support for imp.reload()
2011-02-20 23:39:29 +00:00
# Global Defines
BKE_assert(), only prints the error unless cmake define WITH_ASSERT_ABORT is enabled and it will call abort(). made this option advanced so people don't enable along with other features.
2010-12-15 10:22:26 +00:00
if(WITH_ASSERT_ABORT)
add_definitions(-DWITH_ASSERT_ABORT)
endif()
CMake: Allow asserts to be enabled for release builds. 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
2023-12-06 23:49:42 +01:00
# NDEBUG is the standard C define to disable asserts.
if(WITH_ASSERT_RELEASE)
# CMake seemingly be setting the NDEBUG flag on its own already on some configurations
# therefore we need to remove the flags if they happen to be set.
remove_cc_flag("-DNDEBUG") # GCC/CLang
remove_cc_flag("/DNDEBUG") # MSVC
else()
set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS
$<$<CONFIG:Release>:NDEBUG>
$<$<CONFIG:MinSizeRel>:NDEBUG>
$<$<CONFIG:RelWithDebInfo>:NDEBUG>
)
endif()
last commit to fix warnings didnt set them at all, not it works as it should. also made cmakes output a lot quieter, messages can be uncommented for debugging or added back if other devs need this for some reason.
2010-12-16 12:48:30 +00:00
# message(STATUS "Using CFLAGS: ${CMAKE_C_FLAGS}")
# message(STATUS "Using CXXFLAGS: ${CMAKE_CXX_FLAGS}")
Cleanup: move CMake test utility functions into testing.cmake Combining functions from macros.cmake and Modules/GTestTesting.cmake. It was unusual to have Blender specific code in the Modules folder. Pull Request: https://projects.blender.org/blender/blender/pulls/116719
2024-01-03 14:49:11 +01:00
# -----------------------------------------------------------------------------
# Testing Functions
include(build_files/cmake/testing.cmake)
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Add Sub-Directories
CMake: use a global list to store libraries built rather then cmake_blender_libs.txt file.
2010-12-06 10:56:37 +00:00
Disable GAME ENGINE from the build options
2018-04-16 15:54:36 +02:00
if(WITH_BLENDER)
Cycles: Add a cmake config to easily compile Cycles Standalone. On Linux/Mac OS X, simply type "make cycles" inside the Blender source directory, to get a standalone build of the engine. Reviewed by: Brecht Differential Revision: https://developer.blender.org/D228
2014-01-20 20:41:54 +01:00
add_subdirectory(intern)
add_subdirectory(extern)
GTest unit testing framework Currently covers only small set of functionality.
2014-06-18 22:49:17 +10:00
# source after intern and extern to gather all
# internal and external library information first, for test linking
add_subdirectory(source)
Cycles: Add Hydra render delegate This patch adds a Hydra render delegate to Cycles, allowing Cycles to be used for rendering in applications that provide a Hydra viewport. The implementation was written from scratch against Cycles X, for integration into the Blender repository to make it possible to continue developing it in step with the rest of Cycles. For this purpose it follows the style of the rest of the Cycles code and can be built with a CMake option (`WITH_CYCLES_HYDRA_RENDER_DELEGATE=1`) similar to the existing standalone version of Cycles. Since Hydra render delegates need to be built against the exact USD version and other dependencies as the target application is using, this is intended to be built separate from Blender (`WITH_BLENDER=0` CMake option) and with support for library versions different from what Blender is using. As such the CMake build scripts for Windows had to be modified slightly, so that the Cycles Hydra render delegate can e.g. be built with MSVC 2017 again even though Blender requires MSVC 2019 now, and it's possible to specify custom paths to the USD SDK etc. The codebase supports building against the latest USD release 22.03 and all the way back to USD 20.08 (with some limitations). Reviewed By: brecht, LazyDodo Differential Revision: https://developer.blender.org/D14398
2022-03-23 16:07:43 +01:00
elseif(WITH_CYCLES_STANDALONE OR WITH_CYCLES_HYDRA_RENDER_DELEGATE)
Fix: Cycles standalone build failures Pull Request: https://projects.blender.org/blender/blender/pulls/122718
2024-06-04 19:04:29 +02:00
add_subdirectory(intern/atomic)
Cycles standalone: fix missing dependencies in CMake files Also set default CYCLES_INSTALL_PATH to CMAKE_INSTALL_PREFIX. By default with a `make cycles` this will build to ${CMAKE_BINARY_DIR}/bin Differential Revision: https://developer.blender.org/D9961
2021-01-18 07:43:42 +01:00
add_subdirectory(intern/guardedalloc)
add_subdirectory(intern/libc_compat)
add_subdirectory(intern/sky)
Cycles: Add a cmake config to easily compile Cycles Standalone. On Linux/Mac OS X, simply type "make cycles" inside the Blender source directory, to get a standalone build of the engine. Reviewed by: Brecht Differential Revision: https://developer.blender.org/D228
2014-01-20 20:41:54 +01:00
add_subdirectory(intern/cycles)
Cycles: Add option to directly link against CUDA libraries The main purpose of such linking is to make Blender compatible with NVidia's debuggers and profilers which are doing some LD_PRELOAD magic to intercept some function calls. Such magic conflicts with our CUDA wrangler magic and causes segmentation faults. The option is disabled by default, so there's no affect on any of artists. In order to make Blender linked directly against CUDA library use the WITH_CUDA_DYNLOAD CMake option (it's marked as advanced).
2016-01-14 12:24:09 +05:00
if(WITH_CUDA_DYNLOAD)
add_subdirectory(extern/cuew)
endif()
Cycles: add HIP device support for AMD GPUs NOTE: this feature is not ready for user testing, and not yet enabled in daily builds. It is being merged now for easier collaboration on development. HIP is a heterogenous compute interface allowing C++ code to be executed on GPUs similar to CUDA. It is intended to bring back AMD GPU rendering support on Windows and Linux. https://github.com/ROCm-Developer-Tools/HIP. As of the time of writing, it should compile and run on Linux with existing HIP compilers and driver runtimes. Publicly available compilers and drivers for Windows will come later. See task T91571 for more details on the current status and work remaining to be done. Credits: Sayak Biswas (AMD) Arya Rafii (AMD) Brian Savery (AMD) Differential Revision: https://developer.blender.org/D12578
2021-09-28 16:51:14 +02:00
if(WITH_HIP_DYNLOAD)
add_subdirectory(extern/hipew)
endif()
Cycles: Add a cmake config to easily compile Cycles Standalone. On Linux/Mac OS X, simply type "make cycles" inside the Blender source directory, to get a standalone build of the engine. Reviewed by: Brecht Differential Revision: https://developer.blender.org/D228
2014-01-20 20:41:54 +01:00
endif()
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Add Testing Directory
Tests: run suites instead of individual test cases Group all tests of a test suite into a single test command invocation. This reduces the number of invocations by `ctest` by an order of magnitude. Since rB56aa5b0d8c6b663, `bin/tests/blender_test` was run for every individual test. Having over a 1000 tests made testing slower than necessary. Individual tests can still be run if desired by invocation of `bin/tests/blender_test --gtest_filter=suitename.testname`. NOTE: For this commit to have an immediate effect, it may be necessary to remove the `tests` and `Testing` directories and some CMake files from your build directory and rebuild. Run `ctest -N` to see the list of tests; there should be less than 200. Reviewed By: sergey, LazyDodo, sebbas Maniphest Tasks: T83222 Differential Revision: https://developer.blender.org/D9649
2021-01-11 11:29:30 +01:00
add_subdirectory(tests)
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Add Blender Application
Advanced CMake option to build the player without blender: WITH_BLENDER
2011-07-13 08:15:06 +00:00
if(WITH_BLENDER)
add_subdirectory(source/creator)
endif()
CMake lists initial submission. Documentationand further verification for different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
2006-11-17 02:27:12 +00:00
Patch 17508: Blender Web Plugin - XEmbed. Enable XEmbed integration of blenderplayer, using -i as input parameter to pass embedder window id. create a minimal web plugin to embed blenderplayer on web pages (using gecko/mozilla as browser). Only for *nix.
2008-09-09 21:15:30 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
# Define 'heavy' sub-modules (for Ninja builder when using pools)
CMake: Add support of Ninja's pools to ease building on limited amount of RAM. Many modern computers support a lot of threads (parrallel building jobs), but are somewhat restricted in memory, when some building jobs can require several GB each. Ninja builder has pools, which extend the usual `-j X` make parallelizing option, by allowing to specify different numbers of parallel jobs for different targets. This commit defines three pools, one for linking, one for usual compile, and one for compiling some 'heavy' cpp libs, when a single file can require GB of RAM in full debug builds. Simply enabling WITH_NINJA_POOL_JOBS will try to set default sensible values for those three pools based on your machine specifications, you can then tweak further the values of NINJA_MAX_NUM_PARALLEL_ settings, if you like. On my system (8 cores, 16GB RAM), it allows to build a full debug with all ASAN options build with roughly 7GB of RAM used at most, pretty much as quickly as without that option (which would require up to 11GB of available RAM at some points). Review task: D4780.
2019-05-07 20:32:14 +02:00
setup_heavy_lib_pool()
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
CPack packaging support from Dan Eicher, tested to build redhat RPM's, a Mac bundle also defined.
2011-02-15 18:33:05 +00:00
# CPack for generating packages
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
CPack packaging support from Dan Eicher, tested to build redhat RPM's, a Mac bundle also defined.
2011-02-15 18:33:05 +00:00
include(build_files/cmake/packaging.cmake)
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
Introduce Python code generator for OpenAPI spec to dataclasses Add a [Python code generator][1] that takes an OpenAPI definition and outputs the corresponding data model as [dataclasses][2] This is intended to be used in the Remote Asset Library project, to create, download, parse, and validate information of a remote asset library. [1]: https://koxudaxi.github.io/datamodel-code-generator/ [2]: https://docs.python.org/3/library/dataclasses.html ## Running the Generator The generator is a Python script, which creates its own Python virtualenv, installs the dependencies it needs, and then runs the generator within that virtualenv. The script is intended to run via the `generate_datamodels` CMake target. For example, `ninja generate_datamodels` in the build directory. ## Details The virtualenv is created in Blender's build directory, and is not cleaned up after running. This means that subsequent runs will just use it directly, instead of reinstalling dependencies on every run. ## Generated Code & Interaction with Build System It is my intention that the code generation _only_ happens when the OpenAPI specification changes. This means that the generated code will be committed to Git like any hand-written code. Building Blender will therefore _not_ require the code generator to run. Only people working on the area that uses the generated code will have to deal with this. Pull Request: https://projects.blender.org/blender/blender/pulls/139495
2025-08-01 16:33:56 +02:00
# -----------------------------------------------------------------------------
# OpenAPI-based Python code generator for data models
include(build_files/cmake/generate_datamodels.cmake)
Cleanup: improve titles for CMake sections, line length Also use same convention for comments as (space after #).
2022-09-13 13:46:51 +10:00
# -----------------------------------------------------------------------------
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
# Print Final Configuration
if(FIRST_RUN)
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
set(_config_msg "\nBlender Configuration\n=====================")
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
function(info_cfg_option
_setting
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
set(_msg " - ${_setting}")
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
string(LENGTH "${_msg}" _len)
CMake: Give some extra space to info_cfg_option WITH_PYTHON_INSTALL_ZSTANDARD was too long and didn't align very well compared to the other items in the list.
2022-03-25 14:33:39 -06:00
while("36" GREATER "${_len}")
Cleanup: use string APPEND/PREPEND Replace 'set' with 'string(APPEND/PREPEND ...)'. This avoids duplicating the variable name.
2020-11-06 10:29:04 +11:00
string(APPEND _msg " ")
Cleanup: cmake, indentation, line length
2016-05-18 11:58:08 +10:00
math(EXPR _len "${_len} + 1")
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
endwhile()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
set(_config_msg "${_config_msg}\n${_msg}${${_setting}}" PARENT_SCOPE)
endfunction()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
function(info_cfg_text
_text
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use functions instead of macros Reduces issues with vars leaking into the parent scope.
2015-06-17 09:16:17 +10:00
set(_config_msg "${_config_msg}\n\n ${_text}" PARENT_SCOPE)
endfunction()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: check CMAKE_C_COMPILER_ID instead of CMAKE_CXX_COMPILER_ID While its possible to have different C/C++ compilers, we dont support this at the moment, so just check C compiler ID for now.
2013-12-02 11:36:33 +11:00
message(STATUS "C Compiler: \"${CMAKE_C_COMPILER_ID}\"")
message(STATUS "C++ Compiler: \"${CMAKE_CXX_COMPILER_ID}\"")
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("Build Options:")
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_ALEMBIC)
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_option(WITH_BULLET)
Cmake/deps: Update OSL to 1.11.10.0 This bumps OSL to 1.11.10.0. OSL Has a new build time dependency: Clang, and more importantly it expects clang and llvm to share a library folder, which it previously for us did not. This patch changes: -OSL Update to 1.11.10.0 -refactor the llvm/clang/clang-tools-extra builds into the llvm build using the llvm-project tarball for building that has all of the subprojects in it. -update ispc/openmp builds since clang no longer its own dependency and they have to depend on the llvm build now. -Update the windows builder to use the 64 bit host tools since it ran out of ram linking clang -Since OSL now needs clang to link successfully a findclang.cmake has been provided for linux/OSX Differential Revision: https://developer.blender.org/D10212 Reviewed By: brecht, sebbas, sybren
2021-02-24 07:13:37 -07:00
info_cfg_option(WITH_CLANG)
Cycles: svn merge -r41613:41627 ^/trunk/blender
2011-11-07 17:13:32 +00:00
info_cfg_option(WITH_CYCLES)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_FFTW3)
fix for building on osx with recent freestyle bugfix.
2013-05-24 10:15:20 +00:00
info_cfg_option(WITH_FREESTYLE)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_GMP)
CMake/Windows/macOS: Add Libharu Decision: https://lists.blender.org/pipermail/bf-committers/2020-December/050836.html Adds CMake dependency builder support. Tested on macOS and Windows (Thanks @LazyDodo). Reviewed By: #platform_macos, LazyDodo, sebbas Maniphest Task: T84836 Differential Revision: https://developer.blender.org/D9928
2021-02-01 21:58:57 +05:30
info_cfg_option(WITH_HARU)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_IK_ITASC)
info_cfg_option(WITH_IK_SOLVER)
info_cfg_option(WITH_INPUT_NDOF)
macOS: support Japanese input for text buttons Blender did not support to input East Asian characters (Chinese, Japanese, Korean) on macOS. This patch adds support for Japanese input, by implementing the appropriate processing for the NSTextInputClient protocol. Technical notes: * The conversion candidate window is drawn by the input method program calling `firstRectForCharacterRange`. * The string before confirmation (called `composite` in blender) is handled in the `setMarkedText` method called by the input method program. * The string after confirmation (called `result` in the blender) is processed in the `insertText` method called by the input method program. Ref T51283 Differential Revision: https://developer.blender.org/D11695
2021-07-05 13:11:17 +02:00
info_cfg_option(WITH_INPUT_IME)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_INTERNATIONAL)
Modeling: Add a new boolean solver based on the Manifold library. Adds the 'manifold' solver option to the Boolean geo node and to the Boolean modifier. This solver is about as fast, or faster, than the current float solver, and is robust against floating point issues like the Exact solver. But currently it only works on mesh arguments that are strictly manifold. See https://projects.blender.org/blender/blender/issues/120182 for many more details.
2025-04-22 21:23:37 -04:00
info_cfg_option(WITH_MANIFOLD)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
info_cfg_option(WITH_OPENCOLORIO)
Compositor: Added denoising node This node is built on Intel's OpenImageDenoise library. Other denoisers could be integrated, for example Lukas' Cycles denoiser. Compositor: Made OpenImageDenoise optional, added CMake and build_env files to find OIDN Compositor: Fixed some warnings in the denoising operator build_environment: Updated OpenImageDenoise to 0.8.1 build_environment: Updated OpenImageDenoise in `make deps` for macOS Reviewers: sergey, jbakker, brecht Reviewed By: brecht Subscribers: YAFU, LazyDodo, Zen_YS, slumber, samgreen, tjvoll, yeus, ponomarovmax, getrad, coder.kalyan, vitos1k, Yegor, DeepBlender, kumaran7, Darkfie9825, aliasguru, aafra, ace_dragon, juang3d, pandrodor, cdog, lordodin, jtheninja, mavek, marcog, 5k1n2, Atair, rawalanche, 0o00o0oo, filibis, poor, lukasstockner97 Tags: #compositing Differential Revision: https://developer.blender.org/D4304
2019-08-14 15:30:26 +02:00
info_cfg_option(WITH_OPENIMAGEDENOISE)
Build: Add config print for WITH_AUDASPACE and WITH_OPENSUBDIV This commit adds two entries into the "Build Options:" CMake print to assist in verifying configuration both locally and on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/133409
2025-01-22 21:05:26 +01:00
info_cfg_option(WITH_OPENSUBDIV)
Implementation of OpenVDB as a possible cache format for smoke simulations. This commits implements OpenVDB as an extra cache format in the Point Cache system for smoke simulations. Compilation with the library is turned off by default for now, and shall be enabled when the library is present. A documentation of its doings is available here: http:// wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport. A guide to compile OpenVDB can be found here (Linux): http:// wiki.blender.org/index.php?title=Dev:Doc/Building_Blender/Linux/ Dependencies_From_Source#OpenVDB Reviewers: sergey, lukastoenne, brecht, campbellbarton Reviewed By: brecht, campbellbarton Subscribers: galenb, Blendify, robocyte, Lapineige, bliblubli, jtheninja, lukasstockner97, dingto, brecht Differential Revision: https://developer.blender.org/D1721
2016-01-23 08:39:29 +01:00
info_cfg_option(WITH_OPENVDB)
Fix: incomplete integration of PugiXML and Potrace build options Add them to the standard build configurations, disable properly when library not found and print as part of configuration overview.
2021-01-26 15:27:57 +01:00
info_cfg_option(WITH_POTRACE)
info_cfg_option(WITH_PUGIXML)
Add QuadriFlow remesher
2019-08-26 18:34:11 +02:00
info_cfg_option(WITH_QUADRIFLOW)
Build: print TBB ON/OFF state on first configure, cleanup old TBB logic
2020-05-04 23:58:48 +02:00
info_cfg_option(WITH_TBB)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_USD)
Build: library updates for Blender 3.5 This updates the libraries dependencies for VFX platform 2023, and adds various new libraries. It also enables Python bindings and switches from static to shared for various libraries. The precompiled libraries for all platforms will be updated to these new versions in the coming weeks. New: Fribidi 1.0.12 Harfbuzz 5.1.0 MaterialX 1.38.6 (shared lib with python bindings) Minizipng 3.0.7 Pybind11 2.10.1 Shaderc 2022.3 Vulkan 1.2.198 Updated: Boost 1.8.0 (shared lib) Cython 0.29.30 Numpy 1.23.2 OpenColorIO 2.2.0 (shared lib with python bindings) OpenImageIO 2.4.6.0 (shared lib with python bindings) OpenSubdiv 3.5.0 OpenVDB 10.0.0 (shared lib with python bindings) OSL 1.12.7.1 (enable nvptx backend) TBB (shared lib) USD 22.11 (shared lib with python bindings, enable hydra) yaml-cpp 0.8.0 Includes contributions by Ray Molenkamp, Brecht Van Lommel, Georgiy Markelov and Campbell Barton. Ref T99618
2022-12-05 23:18:54 +01:00
info_cfg_option(WITH_MATERIALX)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_XR_OPENXR)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("Compiler Options:")
info_cfg_option(WITH_BUILDINFO)
Build: Add WITH_OPTIMIZED_BUILD_TOOLS Enable optimizations on Debug builds for executables used for the build process (datatoc and glsl_preprocess) and enable unity builds for shader preprocessing targets. Debug: From 28.9s to 5.7s Release: From 4.9s to 3.5s Pull Request: https://projects.blender.org/blender/blender/pulls/138274
2025-05-02 18:33:44 +02:00
info_cfg_option(WITH_OPTIMIZED_BUILD_TOOLS)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("System Options:")
info_cfg_option(WITH_INSTALL_PORTABLE)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_MEM_JEMALLOC)
info_cfg_option(WITH_MEM_VALGRIND)
Build: show X11 & Wayland options on first run
2022-10-08 13:15:09 +11:00
info_cfg_text("GHOST Options:")
info_cfg_option(WITH_GHOST_DEBUG)
info_cfg_option(WITH_GHOST_SDL)
if(UNIX AND NOT APPLE)
info_cfg_option(WITH_GHOST_X11)
info_cfg_option(WITH_GHOST_WAYLAND)
if(WITH_GHOST_X11)
info_cfg_option(WITH_GHOST_XDND)
info_cfg_option(WITH_X11_XFIXES)
info_cfg_option(WITH_X11_XINPUT)
endif()
if(WITH_GHOST_WAYLAND)
info_cfg_option(WITH_GHOST_WAYLAND_DYNLOAD)
info_cfg_option(WITH_GHOST_WAYLAND_LIBDECOR)
endif()
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("Image Formats:")
info_cfg_option(WITH_IMAGE_CINEON)
info_cfg_option(WITH_IMAGE_OPENEXR)
info_cfg_option(WITH_IMAGE_OPENJPEG)
Cleanup: format, sort CMake file lists
2023-03-10 12:48:35 +11:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("Audio:")
Build: Add config print for WITH_AUDASPACE and WITH_OPENSUBDIV This commit adds two entries into the "Build Options:" CMake print to assist in verifying configuration both locally and on the buildbot. Pull Request: https://projects.blender.org/blender/blender/pulls/133409
2025-01-22 21:05:26 +01:00
info_cfg_option(WITH_AUDASPACE)
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_option(WITH_CODEC_FFMPEG)
info_cfg_option(WITH_CODEC_SNDFILE)
Audaspace: add support for CoreAudio on macOS This adds CoreAudio as audio backend on macOS. CoreAudio is the standard audio API on macOS. Ref T86590
2021-03-14 12:46:47 +01:00
info_cfg_option(WITH_COREAUDIO)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_JACK)
info_cfg_option(WITH_JACK_DYNLOAD)
info_cfg_option(WITH_OPENAL)
Audaspace: add support for PulseAudio on Linux This adds PulseAudio as audio backend on Linux. PulseAudio is the main audio engine used on most, if not all, Linux distributions today. Ref T86590
2021-03-02 17:29:18 +01:00
info_cfg_option(WITH_PULSEAUDIO)
info_cfg_option(WITH_PULSEAUDIO_DYNLOAD)
Cleanup/CMake: Fix comment, sort order of options.
2021-03-23 12:11:46 +05:30
info_cfg_option(WITH_SDL)
Audaspace: add support for WASAPI on Windows This adds WASAPI as audio backend on Windows. WASAPI is the modern standard audio API on Windows introduced with Windows Vista. Ref T86590
2021-03-11 19:22:56 +01:00
info_cfg_option(WITH_WASAPI)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("Compression:")
info_cfg_option(WITH_LZMA)
info_cfg_option(WITH_LZO)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: show WITH_HYDRA on first installation Also disable OSL for lite builds, only makes a difference when cycles is enabled for lite builds.
2023-08-10 12:36:31 +10:00
if(WITH_PYTHON)
info_cfg_text("Python:")
info_cfg_option(WITH_PYTHON_INSTALL)
info_cfg_option(WITH_PYTHON_INSTALL_NUMPY)
info_cfg_option(WITH_PYTHON_INSTALL_ZSTANDARD)
info_cfg_option(WITH_PYTHON_MODULE)
info_cfg_option(WITH_PYTHON_SAFETY)
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("Modifiers:")
info_cfg_option(WITH_MOD_FLUID)
rename cmake WITH_OCEANSIM --> WITH_MOD_OCEANSIM and tag CYCLES_CUDA_BINARIES_ARCH as advanced.
2011-11-13 14:16:43 +00:00
info_cfg_option(WITH_MOD_OCEANSIM)
Cleanup: Fix the order of info_cfg_option.
2020-11-06 12:45:25 +05:30
info_cfg_option(WITH_MOD_REMESH)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: show WITH_HYDRA on first installation Also disable OSL for lite builds, only makes a difference when cycles is enabled for lite builds.
2023-08-10 12:36:31 +10:00
info_cfg_text("Rendering:")
info_cfg_option(WITH_HYDRA)
Build: also list Cycles build options on first cmake config
2022-10-04 19:31:24 +02:00
if(WITH_CYCLES)
CMake: show WITH_HYDRA on first installation Also disable OSL for lite builds, only makes a difference when cycles is enabled for lite builds.
2023-08-10 12:36:31 +10:00
info_cfg_text("Rendering (Cycles):")
Build: also list Cycles build options on first cmake config
2022-10-04 19:31:24 +02:00
info_cfg_option(WITH_CYCLES_OSL)
info_cfg_option(WITH_CYCLES_EMBREE)
info_cfg_option(WITH_CYCLES_PATH_GUIDING)
if(NOT APPLE)
info_cfg_option(WITH_CYCLES_DEVICE_OPTIX)
info_cfg_option(WITH_CYCLES_DEVICE_CUDA)
info_cfg_option(WITH_CYCLES_CUDA_BINARIES)
info_cfg_option(WITH_CYCLES_DEVICE_ONEAPI)
info_cfg_option(WITH_CYCLES_ONEAPI_BINARIES)
Cycles: add HIP RT device, for AMD hardware ray tracing on Windows HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a to shader implementation for older graphics cards. It offers an average 25% sample rendering rate improvement in Cycles benchmarks, on a W6800 card. The ray tracing feature functions are accessed through HIP RT SDK, available on GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and shipped with the SDK. This is not yet enabled as there are issues to be resolved, but landing the code now makes testing and further changes easier. Known limitations: * Not working yet with current public AMD drivers. * Visual artifact in motion blur. * One of the buffers allocated for traversal has a static size. Allocating it dynamically would reduce memory usage. * This is for Windows only currently, no Linux support. Co-authored-by: Brecht Van Lommel <brecht@blender.org> Ref #105538
2023-04-24 19:05:30 +02:00
info_cfg_option(WITH_CYCLES_DEVICE_HIP)
info_cfg_option(WITH_CYCLES_HIP_BINARIES)
info_cfg_option(WITH_CYCLES_DEVICE_HIPRT)
Build: also list Cycles build options on first cmake config
2022-10-04 19:31:24 +02:00
endif()
endif()
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
info_cfg_text("")
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: pass a mode argument to message While omitting the mode is supported it's generally better to clarify the purpose of a message.
2025-04-05 20:41:33 +11:00
message(STATUS "${_config_msg}")
since cmake new auto-detects many features, print a summery of the configuration on first run.
2011-06-19 13:49:20 +00:00
endif()
CMake: cleanup, namespace & unused vars also add macro 'print_all_vars()', if(0)'d - debugging only.
2014-11-16 12:57:42 +01:00
if(0)
print_all_vars()
endif()
CMake: Support external callback in configuration An external CMake script can be used to debug CMake code, modify/read target properties, inter-target dependencies, non-cache variables etc. Reviewed by: LazyDodo, brecht Differential Revision: https://developer.blender.org/D13830
2022-01-20 00:15:09 +05:30
# Should be the last step of configuration.
if(POSTCONFIGURE_SCRIPT)
include(${POSTCONFIGURE_SCRIPT})
endif()
Reference in New Issue Copy Permalink