archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
a02fa6c40d298b187bd8d85afba9e0148b7e001d
blender-archive/build_files/cmake/platform/platform_win32.cmake

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

1048 lines
41 KiB
CMake
Raw Normal View History

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
# Copyright 2016 Blender Foundation. All rights reserved.
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
# Libraries configuration for Windows.
add_definitions(-DWIN32)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(NOT MSVC)
Remove MinGW support The Issue ======= For a long time now MinGW has been unsupported and unmaintained and at this point, it looks like something that we should just leave behind and move on. Why Remove ========== One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based. However, now that this is no longer true we have basically stopped updating the need CMake files. Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see: https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch If we wanted to keep MinGW then we would need to make more custom patches to the external libs and this is not something our platform maintainers are willing to do. For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3 Fixes T51301 Differential Revision: https://developer.blender.org/D2648
2017-05-27 15:34:55 -04:00
message(FATAL_ERROR "Compiler is unsupported")
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
endif()
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
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(MSVC_CLANG ON)
make.bat: cache the vcredist directory. When run from make.bat the environment is setup correctly and the VCToolsRedistDir environment variable exists, on later invocations of cmake this may no longer be the case and a warning was emitted about the missing runtime. we can't rely on InstallRequiredSystemLibraries.cmake here since it uses the compiler version to figure out the correct location and it doesn't know how to deal with clang.
2018-06-05 07:25:37 -06:00
set(VC_TOOLS_DIR $ENV{VCToolsRedistDir} CACHE STRING "Location of the msvc redistributables")
set(MSVC_REDIST_DIR ${VC_TOOLS_DIR})
Cleanup: style, indentation
2019-06-19 07:24:55 +10:00
if(DEFINED MSVC_REDIST_DIR)
make.bat : improve error message while detecting the msvc runtime when using clang
2018-05-28 20:07:24 -06:00
file(TO_CMAKE_PATH ${MSVC_REDIST_DIR} MSVC_REDIST_DIR)
else()
message("Unable to detect the Visual Studio redist directory, copying of the runtime dlls will not work, try running from the visual studio developer prompt.")
endif()
CMake: Add support for building with OpenMP support for clang on windows. mostly minor c/cxx/linker flags, only tested with clang 9.0.0 Differential Revision: https://developer.blender.org/D5976 Reviewers: brecht, jesterking
2019-10-07 10:24:13 -06:00
# 1) CMake has issues detecting openmp support in clang-cl so we have to provide
# the right switches here.
# 2) While the /openmp switch *should* work, it currently doesn't as for clang 9.0.0
if(WITH_OPENMP)
set(OPENMP_CUSTOM ON)
set(OPENMP_FOUND ON)
set(OpenMP_C_FLAGS "/clang:-fopenmp")
set(OpenMP_CXX_FLAGS "/clang:-fopenmp")
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
get_filename_component(LLVMROOT "[HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\LLVM\\LLVM;]" ABSOLUTE CACHE)
CMake: Add support for building with OpenMP support for clang on windows. mostly minor c/cxx/linker flags, only tested with clang 9.0.0 Differential Revision: https://developer.blender.org/D5976 Reviewers: brecht, jesterking
2019-10-07 10:24:13 -06:00
set(CLANG_OPENMP_DLL "${LLVMROOT}/bin/libomp.dll")
set(CLANG_OPENMP_LIB "${LLVMROOT}/lib/libomp.lib")
if(NOT EXISTS "${CLANG_OPENMP_DLL}")
message(FATAL_ERROR "Clang OpenMP library (${CLANG_OPENMP_DLL}) not found.")
endif()
Fix macOS SSE support not detected correctly after recent changes Due to moving the code the test binary was incorrectly compiled with OpenMP flags. Move setting of the OpenMP flags to the appropriate place.
2021-02-25 15:02:38 +01:00
set(OpenMP_LINKER_FLAGS "\"${CLANG_OPENMP_LIB}\"")
CMake: Add support for building with OpenMP support for clang on windows. mostly minor c/cxx/linker flags, only tested with clang 9.0.0 Differential Revision: https://developer.blender.org/D5976 Reviewers: brecht, jesterking
2019-10-07 10:24:13 -06:00
endif()
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
if(WITH_WINDOWS_STRIPPED_PDB)
message(WARNING "stripped pdb not supported with clang, disabling..")
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(WITH_WINDOWS_STRIPPED_PDB OFF)
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
endif()
Windows: Retire MSVC 2017 support The lower bar for building blender is now MSVC 2019 16.9.16.
2022-01-26 17:56:38 -07:00
else()
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(WITH_BLENDER AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.28.29921) # MSVC 2019 16.9.16
Windows: Retire MSVC 2017 support The lower bar for building blender is now MSVC 2019 16.9.16.
2022-01-26 17:56:38 -07:00
message(FATAL_ERROR "Compiler is unsupported, MSVC 2019 16.9.16 or newer is required for building blender.")
endif()
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
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06: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(WITH_BLENDER AND NOT WITH_PYTHON_MODULE)
msvc: Use source folder structure for project file. This patch changes the huge list of projects in visual studio into a nice tree matching the source folder structure. see D2823 for details. Differential Revision: http://developer.blender.org/D2823
2018-02-03 16:38:27 -07:00
set_property(DIRECTORY PROPERTY VS_STARTUP_PROJECT blender)
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
macro(warn_hardcoded_paths package_name
)
if(WITH_WINDOWS_FIND_MODULES)
message(WARNING "Using HARDCODED ${package_name} locations")
CMake: cleanup
2017-10-30 12:58:44 +11:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endmacro()
macro(windows_find_package package_name
)
if(WITH_WINDOWS_FIND_MODULES)
find_package(${package_name})
CMake: cleanup
2017-10-30 12:58:44 +11:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endmacro()
macro(find_package_wrapper)
if(WITH_WINDOWS_FIND_MODULES)
find_package(${ARGV})
endif()
endmacro()
add_definitions(-DWIN32)
MSVC: Fix compiling with some system languages Report from @cyaoeu that compiling failed for Japanese system language.
2017-12-10 15:12:31 +11:00
# Needed, otherwise system encoding causes utf-8 encoding to fail in some cases (C4819)
add_compile_options("$<$<C_COMPILER_ID:MSVC>:/utf-8>")
add_compile_options("$<$<CXX_COMPILER_ID:MSVC>:/utf-8>")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
# needed for some MSVC installations
Windows: Silence LNK4099 warning. Ever since debug symbols were added for release builds the linker has been on the chatty side about symbols being missing for our binary libs. There's currently no plans to supply those, so best for the linker not to warn us about them.
2020-05-04 08:29:48 -06:00
# 4099 : PDB 'filename' was not found with 'object/library'
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_EXE_LINKER_FLAGS " /SAFESEH:NO /ignore:4099")
string(APPEND CMAKE_SHARED_LINKER_FLAGS " /SAFESEH:NO /ignore:4099")
string(APPEND CMAKE_MODULE_LINKER_FLAGS " /SAFESEH:NO /ignore:4099")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
list(APPEND PLATFORM_LINKLIBS
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
ws2_32 vfw32 winmm kernel32 user32 gdi32 comdlg32 Comctl32 version
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
advapi32 shfolder shell32 ole32 oleaut32 uuid psapi Dbghelp Shlwapi
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
pathcch Shcore Dwmapi Crypt32
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
)
if(WITH_INPUT_IME)
list(APPEND PLATFORM_LINKLIBS imm32)
endif()
add_definitions(
-D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_SECURE_NO_DEPRECATE
-D_SCL_SECURE_NO_DEPRECATE
-D_CONSOLE
-D_LIB
)
# MSVC11 needs _ALLOW_KEYWORD_MACROS to build
add_definitions(-D_ALLOW_KEYWORD_MACROS)
Cleanup: Fix build warning with MSVC and OSL OSL requires RTTI to be off, this is done with the /GR- flag for MSVC, however /GR is in the default CXX flags leading to warning D9025 : overriding '/GR' with '/GR-' which cannot be suppressed. /GR is on by default and this flag is not required, so removing it from the default CXX flags makes it possible later use /GR- without generating warnings.
2020-08-26 22:20:34 -06:00
# RTTI is on by default even without this switch
# however having it in the CXX Flags makes it difficult
# to remove for individual files that want to disable it
# using the /GR- flag without generating a build warning
# that both /GR and /GR- are specified.
remove_cc_flag("/GR")
Windows: Clean-up win 8/8.1 API use For 2.93 we bumped the minimum windows requirement to windows 8.1, but did not do any clean-up of any win 8/8.1 API usage we dynamically accessed though LoadLibrary/GetProcAddress. This patch bumps _WIN32_WINNT to 0x0603 (win 8.1) and cleans up any API use that was accessed in a more convoluted way than necessary Differential Revision: https://developer.blender.org/D11331 Reviewed by: harley, nicholas_rishel
2021-05-31 08:56:57 -06:00
# Make the Windows 8.1 API available for use.
add_definitions(-D_WIN32_WINNT=0x603)
Windows: install shared libraries in blender.shared Instead of the the same folder as the Blender executable, generate a manifest that lets us move the libraries out of the way of users and into a separate folder. Ref T99618
2022-12-05 23:42:49 +01:00
# First generate the manifest for tests since it will not need the dependency on the CRT.
configure_file(${CMAKE_SOURCE_DIR}/release/windows/manifest/blender.exe.manifest.in ${CMAKE_CURRENT_BINARY_DIR}/tests.exe.manifest @ONLY)
if(WITH_WINDOWS_BUNDLE_CRT)
set(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP TRUE)
set(CMAKE_INSTALL_UCRT_LIBRARIES TRUE)
set(CMAKE_INSTALL_OPENMP_LIBRARIES ${WITH_OPENMP})
include(InstallRequiredSystemLibraries)
# ucrtbase(d).dll cannot be in the manifest, due to the way windows 10 handles
# redirects for this dll, for details see T88813.
foreach(lib ${CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS})
string(FIND ${lib} "ucrtbase" pos)
if(NOT pos EQUAL -1)
list(REMOVE_ITEM CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS ${lib})
install(FILES ${lib} DESTINATION . COMPONENT Libraries)
endif()
endforeach()
# Install the CRT to the blender.crt Sub folder.
install(FILES ${CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS} DESTINATION ./blender.crt COMPONENT Libraries)
windows_generate_manifest(
FILES "${CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS}"
OUTPUT "${CMAKE_BINARY_DIR}/blender.crt.manifest"
NAME "blender.crt"
)
install(FILES ${CMAKE_BINARY_DIR}/blender.crt.manifest DESTINATION ./blender.crt)
set(BUNDLECRT "<dependency><dependentAssembly><assemblyIdentity type=\"win32\" name=\"blender.crt\" version=\"1.0.0.0\" /></dependentAssembly></dependency>")
endif()
Cmake: Fix building with WITH_WINDOWS_BUNDLE_CRT Off When building without WITH_WINDOWS_BUNDLE_CRT the manifest did not contain the blender.shared dependentAssembly leading to missing dll errors at blender startup.
2022-12-21 13:25:02 -07:00
set(BUNDLECRT "${BUNDLECRT}<dependency><dependentAssembly><assemblyIdentity type=\"win32\" name=\"blender.shared\" version=\"1.0.0.0\" /></dependentAssembly></dependency>")
Windows: install shared libraries in blender.shared Instead of the the same folder as the Blender executable, generate a manifest that lets us move the libraries out of the way of users and into a separate folder. Ref T99618
2022-12-05 23:42:49 +01:00
configure_file(${CMAKE_SOURCE_DIR}/release/windows/manifest/blender.exe.manifest.in ${CMAKE_CURRENT_BINARY_DIR}/blender.exe.manifest @ONLY)
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
remove_cc_flag("/MDd" "/MD" "/Zi")
make.bat: Add support for building with ninja. ninja is an alternative to msbuild designed for fast rebuilds. However there is no IDE support, builds only from the command line. Comparison between msbuild and ninja for a full build, build time in seconds. Full Clean Build msbuild 867.5 Ninja 801.2 Difference -66.3 (-7.6%) Minor Change msbuild 43.0 Ninja 14.9 Difference -28.1 (-64.4%) No Changes msbuild 23.0 Ninja 6.1 Difference -16.9 (-73.5%)
2018-05-25 21:46:42 -06:00
Cleanup: trailing space in CMake files
2018-06-10 08:12:13 +02:00
if(MSVC_CLANG) # Clangs version of cl doesn't support all flags
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 " ${CXX_WARN_FLAGS} /nologo /J /Gd /EHsc -Wno-unused-command-line-argument -Wno-microsoft-enum-forward-reference ")
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
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /nologo /J /Gd -Wno-unused-command-line-argument -Wno-microsoft-enum-forward-reference")
else()
Windows/Ninja: Optimize linker performance The /Zc:inline flag is by default off in the MSVC compiler however when you build with msbuild it adds it to the build flags on its own. Ninja however does not decide on its own to add flags you didn't ask for and was building without this flag. This change explicitly adds the compiler flag so msbuild and ninja builds are once more building with the same build flags leading to smaller .obj files when building with ninja and lightening the workload for the linker. This flag is available starting MSVC 2013 update 2 so does not need to be guarded with version checks.
2021-08-25 10:55:45 -06:00
string(APPEND CMAKE_CXX_FLAGS " /nologo /J /Gd /MP /EHsc /bigobj /Zc:inline")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /nologo /J /Gd /MP /bigobj /Zc:inline")
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
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
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
# X64 ASAN is available and usable on MSVC 16.9 preview 4 and up)
if(WITH_COMPILER_ASAN AND MSVC AND NOT MSVC_CLANG)
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.28.29828)
#set a flag so we don't have to do this comparison all the time
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
set(MSVC_ASAN ON)
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
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /fsanitize=address")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /fsanitize=address")
string(APPEND CMAKE_EXE_LINKER_FLAGS_DEBUG " /INCREMENTAL:NO")
string(APPEND CMAKE_SHARED_LINKER_FLAGS_DEBUG " /INCREMENTAL:NO")
else()
message("-- ASAN not supported on MSVC ${CMAKE_CXX_COMPILER_VERSION}")
endif()
endif()
Cleanup/MSVC: Enable C++ conformance mode on compiler versions that support it. MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly enforced. This mode is available on MSVC 15.5+ [1] This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process. - Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour. - Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard. - Ghost had some scoping issues regarding uninitialized variables and goto behaviour Second landing of this patch, earlier commit was reverted due to some compiler configurations having slipped though testing [1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance Differential Revision: https://developer.blender.org/D6824 Reviewed By: brecht
2020-02-13 17:13:07 -07:00
# C++ standards conformace (/permissive-) is available on msvc 15.5 (1912) and up
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(NOT MSVC_CLANG)
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 " /permissive-")
Cleanup/MSVC: Enable C++ conformance mode on compiler versions that support it. MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly enforced. This mode is available on MSVC 15.5+ [1] This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process. - Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour. - Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard. - Ghost had some scoping issues regarding uninitialized variables and goto behaviour Second landing of this patch, earlier commit was reverted due to some compiler configurations having slipped though testing [1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance Differential Revision: https://developer.blender.org/D6824 Reviewed By: brecht
2020-02-13 17:13:07 -07:00
# Two-phase name lookup does not place nicely with OpenMP yet, so disable for now
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 " /Zc:twoPhase-")
Cleanup/MSVC: Enable C++ conformance mode on compiler versions that support it. MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly enforced. This mode is available on MSVC 15.5+ [1] This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process. - Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour. - Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard. - Ghost had some scoping issues regarding uninitialized variables and goto behaviour Second landing of this patch, earlier commit was reverted due to some compiler configurations having slipped though testing [1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance Differential Revision: https://developer.blender.org/D6824 Reviewed By: brecht
2020-02-13 17:13:07 -07:00
endif()
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
if(WITH_WINDOWS_SCCACHE AND CMAKE_VS_MSBUILD_COMMAND)
message(WARNING "Disabling sccache, sccache is not supported with msbuild")
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(WITH_WINDOWS_SCCACHE OFF)
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
endif()
Cleanup/MSVC: Enable C++ conformance mode on compiler versions that support it. MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly enforced. This mode is available on MSVC 15.5+ [1] This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process. - Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour. - Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard. - Ghost had some scoping issues regarding uninitialized variables and goto behaviour Second landing of this patch, earlier commit was reverted due to some compiler configurations having slipped though testing [1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance Differential Revision: https://developer.blender.org/D6824 Reviewed By: brecht
2020-02-13 17:13:07 -07:00
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
# Debug Symbol format
# sccache # MSVC_ASAN # format # why
Cleanup: cmake comment line length
2022-11-03 12:10:16 +11:00
# ON # ON # Z7 # sccache will only play nice with Z7.
# ON # OFF # Z7 # sccache will only play nice with Z7.
# OFF # ON # Zi # Asan will not play nice with Edit and Continue.
# OFF # OFF # ZI # Neither ASAN nor sscache is enabled Edit and
# Continue is available.
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
# Release Symbol format
# sccache # MSVC_ASAN # format # why
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
# ON # ON # Z7 # sccache will only play nice with Z7
# ON # OFF # Z7 # sccache will only play nice with Z7
# OFF # ON # Zi # Asan will not play nice with Edit and Continue
# OFF # OFF # Zi # Edit and Continue disables some optimizations
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
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
if(WITH_WINDOWS_SCCACHE)
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
set(CMAKE_C_COMPILER_LAUNCHER sccache)
set(CMAKE_CXX_COMPILER_LAUNCHER sccache)
set(SYMBOL_FORMAT /Z7)
set(SYMBOL_FORMAT_RELEASE /Z7)
else()
unset(CMAKE_C_COMPILER_LAUNCHER)
unset(CMAKE_CXX_COMPILER_LAUNCHER)
if(MSVC_ASAN)
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
set(SYMBOL_FORMAT /Z7)
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
set(SYMBOL_FORMAT_RELEASE /Z7)
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
else()
set(SYMBOL_FORMAT /ZI)
set(SYMBOL_FORMAT_RELEASE /Zi)
endif()
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
endif()
if(WITH_WINDOWS_PDB)
Cleanup: tab indentation for CMake / GNUmakefile
2021-08-05 12:02:49 +10:00
set(PDB_INFO_OVERRIDE_FLAGS "${SYMBOL_FORMAT_RELEASE}")
set(PDB_INFO_OVERRIDE_LINKER_FLAGS "/DEBUG /OPT:REF /OPT:ICF /INCREMENTAL:NO")
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
endif()
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 " /MDd ${SYMBOL_FORMAT}")
string(APPEND CMAKE_C_FLAGS_DEBUG " /MDd ${SYMBOL_FORMAT}")
string(APPEND CMAKE_CXX_FLAGS_RELEASE " /MD ${PDB_INFO_OVERRIDE_FLAGS}")
string(APPEND CMAKE_C_FLAGS_RELEASE " /MD ${PDB_INFO_OVERRIDE_FLAGS}")
string(APPEND CMAKE_CXX_FLAGS_MINSIZEREL " /MD ${PDB_INFO_OVERRIDE_FLAGS}")
string(APPEND CMAKE_C_FLAGS_MINSIZEREL " /MD ${PDB_INFO_OVERRIDE_FLAGS}")
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
string(APPEND CMAKE_CXX_FLAGS_RELWITHDEBINFO " /MD ${SYMBOL_FORMAT_RELEASE}")
string(APPEND CMAKE_C_FLAGS_RELWITHDEBINFO " /MD ${SYMBOL_FORMAT_RELEASE}")
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
unset(SYMBOL_FORMAT)
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
unset(SYMBOL_FORMAT_RELEASE)
CMake: add missing headers, use space before comments
2019-10-29 01:32:33 +11:00
# JMC is available on msvc 15.8 (1915) and up
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(NOT MSVC_CLANG)
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 " /JMC")
CMake/Windows: Enable JMC on compilers that support it. JMC [1] enables more productive debugging of C++ code in visual studio this change enables it on debug builds for builds with visual studio 15.8 or higher. [1] https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/
2019-07-30 14:40:05 -06:00
endif()
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_LINKFLAGS " /SUBSYSTEM:CONSOLE /STACK:2097152")
Windows: Switch to the dynamic C runtime This change switches windows to the dynamic C runtime avoiding issues coming from mixing the static and dynamic runtime like the ones outlined in [1] [1] https://developer.blender.org/D5387#122165 Differential Revision: https://developer.blender.org/D6175 Reviewed by: @Sergey
2019-11-08 09:01:00 -07:00
set(PLATFORM_LINKFLAGS_RELEASE "/NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:libcmtd.lib /NODEFAULTLIB:msvcrtd.lib")
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_LINKFLAGS_DEBUG " /IGNORE:4099 /NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:libcmtd.lib")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
# Ignore meaningless for us linker warnings.
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_LINKFLAGS " /ignore:4049 /ignore:4217 /ignore:4221")
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
set(PLATFORM_LINKFLAGS_RELEASE "${PLATFORM_LINKFLAGS} ${PDB_INFO_OVERRIDE_LINKER_FLAGS}")
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_STATIC_LINKER_FLAGS " /ignore:4221")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(CMAKE_CL_64)
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(PREPEND PLATFORM_LINKFLAGS "/MACHINE:X64 ")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
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(PREPEND PLATFORM_LINKFLAGS "/MACHINE:IX86 /LARGEADDRESSAWARE ")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
if(NOT DEFINED LIBDIR)
# Setup 64bit and 64bit windows systems
if(CMAKE_CL_64)
message(STATUS "64 bit compiler detected.")
set(LIBDIR_BASE "win64")
else()
Cleanup/windows: Remove 32 bit support from make.bat helper script This change removes 32 bit support from the helper make.bat scripts as we are dropping official 32 bit support, you can still build for 32 bit by configuring your build yourself using cmake and pointing the LIBDIR cmake variable to your own 32 bit library folder.
2019-08-05 10:31:51 -06:00
message(FATAL_ERROR "32 bit compiler detected, blender no longer provides pre-build libraries for 32 bit windows, please set the LIBDIR cmake variable to your own library folder")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
Windows: Fix VS2022 detection VS2019 had a compiler update moving it into the range that was used to detect VS2022. This patch updates the detection to the current VS2022 preview compiler version. Reported by Jesse Y on chat.
2021-09-09 17:19:58 -06:00
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.30.30423)
Build/Windows: Preliminary VS 2022 support. This adds preliminary VS 2022 support, since there currently is no CMake version that supports the VS2022 IDE only ninja support was tested. IDE support should work without any additional changes as soon as an updated CMake becomes available. As VS2022 appears to keep binary compatibility with earlier MSVC versions, the current SVN libraries will work for this version.
2021-06-21 18:11:30 -06:00
message(STATUS "Visual Studio 2022 detected.")
set(LIBDIR ${CMAKE_SOURCE_DIR}/../lib/${LIBDIR_BASE}_vc15)
elseif(MSVC_VERSION GREATER 1919)
make.bat: Preliminary Visual Studio 2019 support. VS2019 is binary compatible with the existing vc14 libraries and no new libraries libs are required in svn. VS2019 support requires cmake 3.14. VS2019 is still in pre-release state, you are required to explicitly select the pre-release version by using: make full 2019pre
2019-02-22 20:49:22 -07:00
message(STATUS "Visual Studio 2019 detected.")
Windows: Switch to the dynamic C runtime This change switches windows to the dynamic C runtime avoiding issues coming from mixing the static and dynamic runtime like the ones outlined in [1] [1] https://developer.blender.org/D5387#122165 Differential Revision: https://developer.blender.org/D6175 Reviewed by: @Sergey
2019-11-08 09:01:00 -07:00
set(LIBDIR ${CMAKE_SOURCE_DIR}/../lib/${LIBDIR_BASE}_vc15)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
else()
message(STATUS "Using pre-compiled LIBDIR: ${LIBDIR}")
endif()
if(NOT EXISTS "${LIBDIR}/")
Windows: Switch to the dynamic C runtime This change switches windows to the dynamic C runtime avoiding issues coming from mixing the static and dynamic runtime like the ones outlined in [1] [1] https://developer.blender.org/D5387#122165 Differential Revision: https://developer.blender.org/D6175 Reviewed by: @Sergey
2019-11-08 09:01:00 -07:00
message(FATAL_ERROR "\n\nWindows requires pre-compiled libs at: '${LIBDIR}'. Please run `make update` in the blender source folder to obtain them.")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
include(platform_old_libs_update)
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
# Only supported in the VS IDE & Clang Tidy needs to be on.
if(CMAKE_GENERATOR MATCHES "^Visual Studio.+" AND WITH_CLANG_TIDY)
MSVC: Enable clang-tidy analyser This enables the use of clang-tidy in the VS IDE. To use it: 1 - Enable WITH_CLANG_TIDY in your cmake configuration 2 - From the Analyse pull down menu select Run Code Analysis on... The analyser is currently not enabled by default on build given it is quite slow and there are quite a few problems it reports that we still need to deal with.
2020-12-03 11:00:58 -07:00
set(CMAKE_VS_GLOBALS
"RunCodeAnalysis=false"
"EnableMicrosoftCodeAnalysis=false"
"EnableClangTidyCodeAnalysis=true"
)
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(VS_CLANG_TIDY ON)
MSVC: Enable clang-tidy analyser This enables the use of clang-tidy in the VS IDE. To use it: 1 - Enable WITH_CLANG_TIDY in your cmake configuration 2 - From the Analyse pull down menu select Run Code Analysis on... The analyser is currently not enabled by default on build given it is quite slow and there are quite a few problems it reports that we still need to deal with.
2020-12-03 11:00:58 -07:00
endif()
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
# To support building against both 3.4 and 3.5 lib folders, disable materialX if it is not found
set(MATERIALX_LIB_FOLDER_EXISTS EXISTS ${LIBDIR}/materialx)
set_and_warn_library_found("MaterialX" MATERIALX_LIB_FOLDER_EXISTS WITH_MATERIALX)
unset(MATERIALX_LIB_FOLDER_EXISTS)
CMake/MSVC: Mark headers in the libdir as system headers. This marks the headers in the LIBDIR as system headers and changes the warn to /W0 on msvc versions that support it. This resolves some warnings we would had to completely repress otherwise.
2019-05-25 12:13:06 -06:00
# Mark libdir as system headers with a lower warn level, to resolve some warnings
Fix building with ninja on windows Broken by rB161908157d67ee8bcfa0c26917cccdc40e0c67ea
2019-05-26 09:25:17 -06:00
# that we have very little control over
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(NOT MSVC_CLANG AND # Available with MSVC 15.7+ but not for CLANG.
MSVC: Enable clang-tidy analyser This enables the use of clang-tidy in the VS IDE. To use it: 1 - Enable WITH_CLANG_TIDY in your cmake configuration 2 - From the Analyse pull down menu select Run Code Analysis on... The analyser is currently not enabled by default on build given it is quite slow and there are quite a few problems it reports that we still need to deal with.
2020-12-03 11:00:58 -07:00
NOT WITH_WINDOWS_SCCACHE AND # And not when sccache is enabled
NOT VS_CLANG_TIDY) # Clang-tidy does not like these options
Fix building with ninja on windows Broken by rB161908157d67ee8bcfa0c26917cccdc40e0c67ea
2019-05-26 09:25:17 -06:00
add_compile_options(/experimental:external /external:templates- /external:I "${LIBDIR}" /external:W0)
CMake/MSVC: Mark headers in the libdir as system headers. This marks the headers in the LIBDIR as system headers and changes the warn to /W0 on msvc versions that support it. This resolves some warnings we would had to completely repress otherwise.
2019-05-25 12:13:06 -06:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
# Add each of our libraries to our cmake_prefix_path so find_package() could work
file(GLOB children RELATIVE ${LIBDIR} ${LIBDIR}/*)
foreach(child ${children})
if(IS_DIRECTORY ${LIBDIR}/${child})
Cleanup: cmake formatting
2022-12-17 13:30:07 +11:00
list(APPEND CMAKE_PREFIX_PATH ${LIBDIR}/${child})
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
endforeach()
Deps: PugiXML 1.10 This separates out PugiXML that was previously bundled by OIIO. As this linux/mac libs are not available this commit only contains the builder and windows changes, and the option to enable pugixml is guarded by a platform if, this can be removed once all platforms have committed the svn libs. For details see D8628
2020-11-29 14:01:33 -07:00
if(WITH_PUGIXML)
set(PUGIXML_LIBRARIES optimized ${LIBDIR}/pugixml/lib/pugixml.lib debug ${LIBDIR}/pugixml/lib/pugixml_d.lib)
set(PUGIXML_INCLUDE_DIR ${LIBDIR}/pugixml/include)
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(ZLIB_INCLUDE_DIRS ${LIBDIR}/zlib/include)
set(ZLIB_LIBRARIES ${LIBDIR}/zlib/lib/libz_st.lib)
set(ZLIB_INCLUDE_DIR ${LIBDIR}/zlib/include)
set(ZLIB_LIBRARY ${LIBDIR}/zlib/lib/libz_st.lib)
set(ZLIB_DIR ${LIBDIR}/zlib)
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
windows_find_package(ZLIB) # we want to find before finding things that depend on it like png
windows_find_package(PNG)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(NOT PNG_FOUND)
warn_hardcoded_paths(libpng)
set(PNG_PNG_INCLUDE_DIR ${LIBDIR}/png/include)
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(PNG_LIBRARIES ${LIBDIR}/png/lib/libpng.lib ${ZLIB_LIBRARY})
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(PNG "${LIBDIR}/png")
set(PNG_INCLUDE_DIRS "${PNG}/include")
set(PNG_LIBPATH ${PNG}/lib) # not cmake defined
endif()
set(JPEG_NAMES ${JPEG_NAMES} libjpeg)
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
windows_find_package(JPEG REQUIRED)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(NOT JPEG_FOUND)
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
warn_hardcoded_paths(libjpeg)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(JPEG_INCLUDE_DIR ${LIBDIR}/jpeg/include)
set(JPEG_LIBRARIES ${LIBDIR}/jpeg/lib/libjpeg.lib)
endif()
GPU: replace GLEW with libepoxy With libepoxy we can choose between EGL and GLX at runtime, as well as dynamically open EGL and GLX libraries without linking to them. This will make it possible to build with Wayland, EGL, GLVND support while still running on systems that only have X11, GLX and libGL. It also paves the way for headless rendering through EGL. libepoxy is a new library dependency, and is included in the precompiled libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed. Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton and Sergey Sharybin. Ref T76428 Differential Revision: https://developer.blender.org/D15291
2022-08-15 14:58:04 +02:00
set(EPOXY_ROOT_DIR ${LIBDIR}/epoxy)
windows_find_package(Epoxy REQUIRED)
if(NOT EPOXY_FOUND)
set(Epoxy_INCLUDE_DIRS ${LIBDIR}/epoxy/include)
set(Epoxy_LIBRARIES ${LIBDIR}/epoxy/lib/epoxy.lib)
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(PTHREADS_INCLUDE_DIRS ${LIBDIR}/pthreads/include)
dependencies windows: Replace pthreads-win32 2.9.1 with pthreads4w 3.0.0 maintenance seems to have stopped for pthreads-win32
2018-12-11 15:12:56 -07:00
set(PTHREADS_LIBRARIES ${LIBDIR}/pthreads/lib/pthreadVC3.lib)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(FREETYPE ${LIBDIR}/freetype)
set(FREETYPE_INCLUDE_DIRS
${LIBDIR}/freetype/include
${LIBDIR}/freetype/include/freetype2
)
cmake/win: Platform update for freetype 2.11.0 freetype now depends on brotli
2022-01-21 11:40:53 -07:00
set(FREETYPE_LIBRARIES
${LIBDIR}/freetype/lib/freetype2ST.lib
${LIBDIR}/brotli/lib/brotlidec-static.lib
${LIBDIR}/brotli/lib/brotlicommon-static.lib
)
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
windows_find_package(Freetype REQUIRED)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(WITH_FFTW3)
set(FFTW3 ${LIBDIR}/fftw3)
set(FFTW3_LIBRARIES ${FFTW3}/lib/libfftw.lib)
set(FFTW3_INCLUDE_DIRS ${FFTW3}/include)
set(FFTW3_LIBPATH ${FFTW3}/lib)
endif()
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
if(WITH_IMAGE_WEBP)
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(WEBP_INCLUDE_DIRS ${LIBDIR}/webp/include)
set(WEBP_ROOT_DIR ${LIBDIR}/webp)
set(WEBP_LIBRARIES ${LIBDIR}/webp/lib/webp.lib ${LIBDIR}/webp/lib/webpdemux.lib ${LIBDIR}/webp/lib/webpmux.lib)
set(WEBP_FOUND ON)
ImBuf: Add support for WebP image format Currently only supports single image frames (no animation possible). If quality slider is set to 100 then lossless compression will be used, otherwise lossy compression is used. Gives about 35% reduction of filesize save when re-saving splash screens with lossless compression. Also saves much faster, up to 15x faster than PNG with a better compression ratio as a plus. Note, this is currently left disabled until we have WebP libs (see T95206) For testing precompiled libs can be downloaded from Google: https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html Differential Revision: https://developer.blender.org/D1598
2022-03-24 18:24:06 -04:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(WITH_OPENCOLLADA)
set(OPENCOLLADA ${LIBDIR}/opencollada)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENCOLLADA_INCLUDE_DIRS
${OPENCOLLADA}/include/opencollada/COLLADAStreamWriter
${OPENCOLLADA}/include/opencollada/COLLADABaseUtils
${OPENCOLLADA}/include/opencollada/COLLADAFramework
${OPENCOLLADA}/include/opencollada/COLLADASaxFrameworkLoader
${OPENCOLLADA}/include/opencollada/GeneratedSaxParser
)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENCOLLADA_LIBRARIES
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
optimized ${OPENCOLLADA}/lib/opencollada/OpenCOLLADASaxFrameworkLoader.lib
optimized ${OPENCOLLADA}/lib/opencollada/OpenCOLLADAFramework.lib
optimized ${OPENCOLLADA}/lib/opencollada/OpenCOLLADABaseUtils.lib
optimized ${OPENCOLLADA}/lib/opencollada/OpenCOLLADAStreamWriter.lib
optimized ${OPENCOLLADA}/lib/opencollada/MathMLSolver.lib
optimized ${OPENCOLLADA}/lib/opencollada/GeneratedSaxParser.lib
optimized ${OPENCOLLADA}/lib/opencollada/buffer.lib
optimized ${OPENCOLLADA}/lib/opencollada/ftoa.lib
debug ${OPENCOLLADA}/lib/opencollada/OpenCOLLADASaxFrameworkLoader_d.lib
debug ${OPENCOLLADA}/lib/opencollada/OpenCOLLADAFramework_d.lib
debug ${OPENCOLLADA}/lib/opencollada/OpenCOLLADABaseUtils_d.lib
debug ${OPENCOLLADA}/lib/opencollada/OpenCOLLADAStreamWriter_d.lib
debug ${OPENCOLLADA}/lib/opencollada/MathMLSolver_d.lib
debug ${OPENCOLLADA}/lib/opencollada/GeneratedSaxParser_d.lib
debug ${OPENCOLLADA}/lib/opencollada/buffer_d.lib
debug ${OPENCOLLADA}/lib/opencollada/ftoa_d.lib
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
)
cmake/windows: Prepare for 3.4 library changes for opencollada The opencollada dependency will be using an external xml2 library for 3.4. This change allows to build against both old and new style lib folders. As it is a C library it did not need a special debug version.
2022-10-21 07:04:21 -06:00
if(EXISTS ${LIBDIR}/xml2/lib/libxml2s.lib) # 3.4 libraries
list(APPEND OPENCOLLADA_LIBRARIES ${LIBDIR}/xml2/lib/libxml2s.lib)
else()
list(APPEND OPENCOLLADA_LIBRARIES ${OPENCOLLADA}/lib/opencollada/xml.lib)
endif()
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
cmake: adjustments required for lib-upgrade on windows.
2018-08-27 19:37:55 -06:00
list(APPEND OPENCOLLADA_LIBRARIES ${OPENCOLLADA}/lib/opencollada/UTF.lib)
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(PCRE_LIBRARIES
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
optimized ${OPENCOLLADA}/lib/opencollada/pcre.lib
debug ${OPENCOLLADA}/lib/opencollada/pcre_d.lib
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
)
endif()
if(WITH_CODEC_FFMPEG)
set(FFMPEG_INCLUDE_DIRS
${LIBDIR}/ffmpeg/include
${LIBDIR}/ffmpeg/include/msvc
)
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
windows_find_package(FFmpeg)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
if(NOT FFmpeg_FOUND)
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
warn_hardcoded_paths(FFmpeg)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(FFMPEG_LIBRARIES
${LIBDIR}/ffmpeg/lib/avcodec.lib
${LIBDIR}/ffmpeg/lib/avformat.lib
${LIBDIR}/ffmpeg/lib/avdevice.lib
${LIBDIR}/ffmpeg/lib/avutil.lib
${LIBDIR}/ffmpeg/lib/swscale.lib
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
endif()
if(WITH_IMAGE_OPENEXR)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
# Imath and OpenEXR have a single combined build option and include and library variables
# used by the rest of the build system.
set(IMATH_ROOT_DIR ${LIBDIR}/imath)
set(IMATH_VERSION "3.14")
windows_find_package(IMATH REQUIRED)
if(NOT IMATH_FOUND)
set(IMATH ${LIBDIR}/imath)
set(IMATH_INCLUDE_DIR ${IMATH}/include)
set(IMATH_INCLUDE_DIRS ${IMATH_INCLUDE_DIR} ${IMATH}/include/Imath)
set(IMATH_LIBPATH ${IMATH}/lib)
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
if(EXISTS ${IMATH_LIBPATH}/Imath_s.lib)
set(IMATH_POSTFIX _s)
endif()
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
set(IMATH_LIBRARIES
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
optimized ${IMATH_LIBPATH}/Imath${IMATH_POSTFIX}.lib
debug ${IMATH_LIBPATH}/Imath${IMATH_POSTFIX}_d.lib
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
)
endif()
set(OPENEXR_ROOT_DIR ${LIBDIR}/openexr)
set(OPENEXR_VERSION "3.14")
windows_find_package(OPENEXR REQUIRED)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
if(NOT OpenEXR_FOUND)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
warn_hardcoded_paths(OpenEXR)
set(OPENEXR ${LIBDIR}/openexr)
set(OPENEXR_INCLUDE_DIR ${OPENEXR}/include)
Cycles: Add basic support for using OSL with OptiX This patch generalizes the OSL support in Cycles to include GPU device types and adds an implementation for that in the OptiX device. There are some caveats still, including simplified texturing due to lack of OIIO on the GPU and a few missing OSL intrinsics. Note that this is incomplete and missing an update to the OSL library before being enabled! The implementation is already committed now to simplify further development. Maniphest Tasks: T101222 Differential Revision: https://developer.blender.org/D15902
2022-11-09 14:25:32 +01:00
set(OPENEXR_INCLUDE_DIRS ${OPENEXR_INCLUDE_DIR} ${IMATH_INCLUDE_DIRS} ${OPENEXR_INCLUDE_DIR}/OpenEXR)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENEXR_LIBPATH ${OPENEXR}/lib)
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
# Check if the blender 3.3 lib static library eixts
# if not assume this is a 3.4+ dynamic version.
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
if(EXISTS "${OPENEXR_LIBPATH}/OpenEXR_s.lib")
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
set(OPENEXR_POSTFIX _s)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
endif()
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
set(OPENEXR_LIBRARIES
optimized ${OPENEXR_LIBPATH}/Iex${OPENEXR_POSTFIX}.lib
optimized ${OPENEXR_LIBPATH}/IlmThread${OPENEXR_POSTFIX}.lib
optimized ${OPENEXR_LIBPATH}/OpenEXR${OPENEXR_POSTFIX}.lib
optimized ${OPENEXR_LIBPATH}/OpenEXRCore${OPENEXR_POSTFIX}.lib
optimized ${OPENEXR_LIBPATH}/OpenEXRUtil${OPENEXR_POSTFIX}.lib
debug ${OPENEXR_LIBPATH}/Iex${OPENEXR_POSTFIX}_d.lib
debug ${OPENEXR_LIBPATH}/IlmThread${OPENEXR_POSTFIX}_d.lib
debug ${OPENEXR_LIBPATH}/OpenEXR${OPENEXR_POSTFIX}_d.lib
debug ${OPENEXR_LIBPATH}/OpenEXRCore${OPENEXR_POSTFIX}_d.lib
debug ${OPENEXR_LIBPATH}/OpenEXRUtil${OPENEXR_POSTFIX}_d.lib
${IMATH_LIBRARIES}
)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
endif()
if(WITH_IMAGE_TIFF)
# Try to find tiff first then complain and set static and maybe wrong paths
windows_find_package(TIFF)
if(NOT TIFF_FOUND)
warn_hardcoded_paths(libtiff)
set(TIFF_LIBRARY ${LIBDIR}/tiff/lib/libtiff.lib)
set(TIFF_INCLUDE_DIR ${LIBDIR}/tiff/include)
endif()
endif()
if(WITH_JACK)
set(JACK_INCLUDE_DIRS
${LIBDIR}/jack/include/jack
${LIBDIR}/jack/include
)
set(JACK_LIBRARIES optimized ${LIBDIR}/jack/lib/libjack.lib debug ${LIBDIR}/jack/lib/libjack_d.lib)
endif()
if(WITH_PYTHON)
Python: script for packing bpy module as wheel The buildbot will call this script to create a binary .whl file that can be easily installed through pip. This wheel will only work with the same Python version used for Blender. Other minimum system requirements are the same as regular Blender builds. Includes contributions by Campbell Barton. Differential Revision: https://developer.blender.org/D15957
2022-09-15 18:01:15 +02:00
# Cache version for make_bpy_wheel.py to detect.
unset(PYTHON_VERSION CACHE)
set(PYTHON_VERSION "3.10" CACHE STRING "Python version")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
string(REPLACE "." "" _PYTHON_VERSION_NO_DOTS ${PYTHON_VERSION})
deps: python 3.7.4 for windows. This also updates to a new packaging method where python is runnable from the library folder rather than having tarballs in the release folder.
2019-08-13 17:02:19 -06:00
set(PYTHON_LIBRARY ${LIBDIR}/python/${_PYTHON_VERSION_NO_DOTS}/libs/python${_PYTHON_VERSION_NO_DOTS}.lib)
set(PYTHON_LIBRARY_DEBUG ${LIBDIR}/python/${_PYTHON_VERSION_NO_DOTS}/libs/python${_PYTHON_VERSION_NO_DOTS}_d.lib)
msvc: Enable /bigobj on all object files. bf_intern_openvdb makes a significant number of template instantiations causing it go over the maximum number of sections (int16) in a coff file when doing a debug build. This change switches the compiler to use the extended coff format which has this field extended (int32) all linkers post msvc2005 can process this format so there's no reason not to turn this on globally. Clang on windows does not need this change since clang switches implicitly to the extended format when required. [1] [1] https://reviews.llvm.org/rL217812
2019-08-14 17:57:01 -06:00
Python: fix failing tests when building bpy module * Use Python executable from lib folder since it's not installed. * Make bpy module test work for portable install. * Disable gtests which don't work with different Python link flags and shared library locations. Ref D15957
2022-09-15 18:10:44 +02:00
set(PYTHON_EXECUTABLE ${LIBDIR}/python/${_PYTHON_VERSION_NO_DOTS}/bin/python$<$<CONFIG:Debug>:_d>.exe)
deps: python 3.7.4 for windows. This also updates to a new packaging method where python is runnable from the library folder rather than having tarballs in the release folder.
2019-08-13 17:02:19 -06:00
set(PYTHON_INCLUDE_DIR ${LIBDIR}/python/${_PYTHON_VERSION_NO_DOTS}/include)
set(PYTHON_NUMPY_INCLUDE_DIRS ${LIBDIR}/python/${_PYTHON_VERSION_NO_DOTS}/lib/site-packages/numpy/core/include)
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(NUMPY_FOUND ON)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
unset(_PYTHON_VERSION_NO_DOTS)
# uncached vars
set(PYTHON_INCLUDE_DIRS "${PYTHON_INCLUDE_DIR}")
cmake: Fix python linker issues on windows. Recent cmake work made the debug build link both python37.dll and python37_d.dll
2019-04-17 13:26:02 -06:00
set(PYTHON_LIBRARIES debug "${PYTHON_LIBRARY_DEBUG}" optimized "${PYTHON_LIBRARY}" )
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
if(WITH_BOOST)
Build: clean up handling of some Cycles build options * Don't link embree / OSL when WITH_CYCLES is disabled * Simplify lite config by disabling Cycles as a whole using this * Remove code handling the removed WITH_CYCLES_NETWORK option
2021-12-07 18:31:36 +01:00
if(WITH_CYCLES AND WITH_CYCLES_OSL)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(boost_extra_libs wave)
endif()
if(WITH_INTERNATIONAL)
list(APPEND boost_extra_libs locale)
endif()
set(Boost_USE_STATIC_RUNTIME ON) # prefix lib
set(Boost_USE_MULTITHREADED ON) # suffix -mt
set(Boost_USE_STATIC_LIBS ON) # suffix -s
CMake: cleanup
2017-10-30 12:58:44 +11:00
if(WITH_WINDOWS_FIND_MODULES)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
find_package(Boost COMPONENTS date_time filesystem thread regex system ${boost_extra_libs})
CMake: cleanup
2017-10-30 12:58:44 +11:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(NOT Boost_FOUND)
warn_hardcoded_paths(BOOST)
set(BOOST ${LIBDIR}/boost)
set(BOOST_INCLUDE_DIR ${BOOST}/include)
cmake: adjustments required for lib-upgrade on windows.
2018-08-27 19:37:55 -06:00
set(BOOST_LIBPATH ${BOOST}/lib)
CMake/Windows: Detect Boost version Rather than hardcoding the lib names, read boosts version.hpp and extract the version from there. This will make it easier to land lib changes in the near future.
2021-02-22 11:03:44 -07:00
set(BOOST_VERSION_HEADER ${BOOST_INCLUDE_DIR}/boost/version.hpp)
if(EXISTS ${BOOST_VERSION_HEADER})
file(STRINGS "${BOOST_VERSION_HEADER}" BOOST_LIB_VERSION REGEX "#define BOOST_LIB_VERSION ")
if(BOOST_LIB_VERSION MATCHES "#define BOOST_LIB_VERSION \"([0-9_]+)\"")
set(BOOST_VERSION "${CMAKE_MATCH_1}")
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
CMake/Windows: Detect Boost version Rather than hardcoding the lib names, read boosts version.hpp and extract the version from there. This will make it easier to land lib changes in the near future.
2021-02-22 11:03:44 -07:00
if(NOT BOOST_VERSION)
message(FATAL_ERROR "Unable to determine Boost version")
endif()
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
set(BOOST_POSTFIX "vc142-mt-x64-${BOOST_VERSION}")
set(BOOST_DEBUG_POSTFIX "vc142-mt-gyd-x64-${BOOST_VERSION}")
set(BOOST_PREFIX "")
# This is file new in 3.4 if it does not exist, assume we are building against 3.3 libs
set(BOOST_34_TRIGGER_FILE ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_python310-${BOOST_DEBUG_POSTFIX}.lib)
Cleanup: cmake formatting
2022-12-17 13:30:07 +11:00
if(NOT EXISTS ${BOOST_34_TRIGGER_FILE})
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
set(BOOST_DEBUG_POSTFIX "vc142-mt-gd-x64-${BOOST_VERSION}")
set(BOOST_PREFIX "lib")
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(BOOST_LIBRARIES
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
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_date_time-${BOOST_POSTFIX}.lib
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_filesystem-${BOOST_POSTFIX}.lib
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_regex-${BOOST_POSTFIX}.lib
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_system-${BOOST_POSTFIX}.lib
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_thread-${BOOST_POSTFIX}.lib
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_chrono-${BOOST_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_date_time-${BOOST_DEBUG_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_filesystem-${BOOST_DEBUG_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_regex-${BOOST_DEBUG_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_system-${BOOST_DEBUG_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_thread-${BOOST_DEBUG_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_chrono-${BOOST_DEBUG_POSTFIX}.lib
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
)
Cleanup: cmake formatting
2022-12-17 13:30:07 +11:00
if(EXISTS ${BOOST_34_TRIGGER_FILE})
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
if(WITH_USD)
Fix cycles_test link error on macOS due to boost python in new 3.5 libraries The executable would get boost python linking in when not needed, and even when linking to Python libraries there were still unresolved symbols. Instead split off boost python libraries and link them only where needed.
2022-12-07 20:38:28 +01:00
set(BOOST_PYTHON_LIBRARIES
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
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_python310-${BOOST_DEBUG_POSTFIX}.lib
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_python310-${BOOST_POSTFIX}.lib
)
endif()
endif()
Build: clean up handling of some Cycles build options * Don't link embree / OSL when WITH_CYCLES is disabled * Simplify lite config by disabling Cycles as a whole using this * Remove code handling the removed WITH_CYCLES_NETWORK option
2021-12-07 18:31:36 +01:00
if(WITH_CYCLES AND WITH_CYCLES_OSL)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(BOOST_LIBRARIES ${BOOST_LIBRARIES}
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
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_wave-${BOOST_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_wave-${BOOST_DEBUG_POSTFIX}.lib
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
if(WITH_INTERNATIONAL)
set(BOOST_LIBRARIES ${BOOST_LIBRARIES}
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
optimized ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_locale-${BOOST_POSTFIX}.lib
debug ${BOOST_LIBPATH}/${BOOST_PREFIX}boost_locale-${BOOST_DEBUG_POSTFIX}.lib
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
else() # we found boost using find_package
set(BOOST_INCLUDE_DIR ${Boost_INCLUDE_DIRS})
set(BOOST_LIBRARIES ${Boost_LIBRARIES})
set(BOOST_LIBPATH ${Boost_LIBRARY_DIRS})
endif()
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(BOOST_DEFINITIONS "-DBOOST_ALL_NO_LIB")
endif()
if(WITH_OPENIMAGEIO)
windows_find_package(OpenImageIO)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
if(NOT OpenImageIO_FOUND)
set(OPENIMAGEIO ${LIBDIR}/OpenImageIO)
set(OPENIMAGEIO_LIBPATH ${OPENIMAGEIO}/lib)
Cycles: Add basic support for using OSL with OptiX This patch generalizes the OSL support in Cycles to include GPU device types and adds an implementation for that in the OptiX device. There are some caveats still, including simplified texturing due to lack of OIIO on the GPU and a few missing OSL intrinsics. Note that this is incomplete and missing an update to the OSL library before being enabled! The implementation is already committed now to simplify further development. Maniphest Tasks: T101222 Differential Revision: https://developer.blender.org/D15902
2022-11-09 14:25:32 +01:00
set(OPENIMAGEIO_INCLUDE_DIR ${OPENIMAGEIO}/include)
set(OPENIMAGEIO_INCLUDE_DIRS ${OPENIMAGEIO_INCLUDE_DIR})
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
set(OIIO_OPTIMIZED optimized ${OPENIMAGEIO_LIBPATH}/OpenImageIO.lib optimized ${OPENIMAGEIO_LIBPATH}/OpenImageIO_Util.lib)
set(OIIO_DEBUG debug ${OPENIMAGEIO_LIBPATH}/OpenImageIO_d.lib debug ${OPENIMAGEIO_LIBPATH}/OpenImageIO_Util_d.lib)
set(OPENIMAGEIO_LIBRARIES ${OIIO_OPTIMIZED} ${OIIO_DEBUG})
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENIMAGEIO_DEFINITIONS "-DUSE_TBB=0")
set(OPENIMAGEIO_IDIFF "${OPENIMAGEIO}/bin/idiff.exe")
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
# If the .dll does not exist, assume it is a static OIIO
if(NOT EXISTS ${OPENIMAGEIO}/bin/OpenImageIO.dll)
add_definitions(-DOIIO_STATIC_DEFINE)
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
add_definitions(-DOIIO_NO_SSE=1)
endif()
if(WITH_LLVM)
set(LLVM_ROOT_DIR ${LIBDIR}/llvm CACHE PATH "Path to the LLVM installation")
Cleanup: cmake formatting
2022-12-17 13:30:07 +11:00
set(LLVM_INCLUDE_DIRS ${LLVM_ROOT_DIR}/$<$<CONFIG:Debug>:Debug>/include CACHE PATH "Path to the LLVM include directory")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
file(GLOB LLVM_LIBRARY_OPTIMIZED ${LLVM_ROOT_DIR}/lib/*.lib)
if(EXISTS ${LLVM_ROOT_DIR}/debug/lib)
foreach(LLVM_OPTIMIZED_LIB ${LLVM_LIBRARY_OPTIMIZED})
get_filename_component(LIBNAME ${LLVM_OPTIMIZED_LIB} ABSOLUTE)
list(APPEND LLVM_LIBS optimized ${LIBNAME})
endforeach(LLVM_OPTIMIZED_LIB)
file(GLOB LLVM_LIBRARY_DEBUG ${LLVM_ROOT_DIR}/debug/lib/*.lib)
foreach(LLVM_DEBUG_LIB ${LLVM_LIBRARY_DEBUG})
get_filename_component(LIBNAME ${LLVM_DEBUG_LIB} ABSOLUTE)
list(APPEND LLVM_LIBS debug ${LIBNAME})
endforeach(LLVM_DEBUG_LIB)
set(LLVM_LIBRARY ${LLVM_LIBS})
else()
message(WARNING "LLVM debug libs not present on this system. Using release libs for debug builds.")
set(LLVM_LIBRARY ${LLVM_LIBRARY_OPTIMIZED})
endif()
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
if(WITH_OPENCOLORIO)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
windows_find_package(OpenColorIO)
if(NOT OpenColorIO_FOUND)
set(OPENCOLORIO ${LIBDIR}/OpenColorIO)
set(OPENCOLORIO_INCLUDE_DIRS ${OPENCOLORIO}/include)
set(OPENCOLORIO_LIBPATH ${OPENCOLORIO}/lib)
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
if(EXISTS ${OPENCOLORIO_LIBPATH}/libexpatMD.lib) # 3.4
set(OPENCOLORIO_LIBRARIES
optimized ${OPENCOLORIO_LIBPATH}/OpenColorIO.lib
optimized ${OPENCOLORIO_LIBPATH}/libexpatMD.lib
optimized ${OPENCOLORIO_LIBPATH}/pystring.lib
optimized ${OPENCOLORIO_LIBPATH}/libyaml-cpp.lib
debug ${OPENCOLORIO_LIBPATH}/OpencolorIO_d.lib
debug ${OPENCOLORIO_LIBPATH}/libexpatdMD.lib
debug ${OPENCOLORIO_LIBPATH}/pystring_d.lib
cmake: fix windows debug build debug library for yaml-cpp was set to an incorrect name
2022-12-07 09:22:32 -07:00
debug ${OPENCOLORIO_LIBPATH}/libyaml-cpp_d.lib
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
)
set(OPENCOLORIO_DEFINITIONS "-DOpenColorIO_SKIP_IMPORTS")
else()
set(OPENCOLORIO_LIBRARIES
optimized ${OPENCOLORIO_LIBPATH}/OpenColorIO.lib
debug ${OPENCOLORIO_LIBPATH}/OpencolorIO_d.lib
)
endif()
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
if(WITH_OPENVDB)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
windows_find_package(OpenVDB)
if(NOT OpenVDB_FOUND)
set(OPENVDB ${LIBDIR}/openVDB)
set(OPENVDB_LIBPATH ${OPENVDB}/lib)
set(OPENVDB_INCLUDE_DIRS ${OPENVDB}/include)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
set(OPENVDB_LIBRARIES optimized ${OPENVDB_LIBPATH}/openvdb.lib debug ${OPENVDB_LIBPATH}/openvdb_d.lib )
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
endif()
Deps_builder: Update openvdb to a dynamic library This patch changes openvdb from a static to a dynamic library. this is in preparation for enabling pyopenvdb at some point in the future. Differential Revision: https://developer.blender.org/D8282 Reviewed by: brecht
2020-08-13 11:42:05 -06:00
set(OPENVDB_DEFINITIONS -DNOMINMAX -D_USE_MATH_DEFINES)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
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
if(WITH_NANOVDB)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
set(NANOVDB ${LIBDIR}/openvdb)
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
set(NANOVDB_INCLUDE_DIR ${NANOVDB}/include)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
if(NOT EXISTS "${NANOVDB_INCLUDE_DIR}/nanovdb")
# When not found, could be an older lib folder with where nanovdb
# had its own lib folder, to ease the transition period, fall back
# to that copy if the copy in openvdb is not found.
set(NANOVDB ${LIBDIR}/nanoVDB)
set(NANOVDB_INCLUDE_DIR ${NANOVDB}/include)
endif()
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
endif()
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
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
if(WITH_OPENIMAGEDENOISE)
set(OPENIMAGEDENOISE ${LIBDIR}/OpenImageDenoise)
set(OPENIMAGEDENOISE_LIBPATH ${LIBDIR}/OpenImageDenoise/lib)
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
set(OPENIMAGEDENOISE_INCLUDE_DIRS ${OPENIMAGEDENOISE}/include)
msvc: Enable /bigobj on all object files. bf_intern_openvdb makes a significant number of template instantiations causing it go over the maximum number of sections (int16) in a coff file when doing a debug build. This change switches the compiler to use the extended coff format which has this field extended (int32) all linkers post msvc2005 can process this format so there's no reason not to turn this on globally. Clang on windows does not need this change since clang switches implicitly to the extended format when required. [1] [1] https://reviews.llvm.org/rL217812
2019-08-14 17:57:01 -06:00
set(OPENIMAGEDENOISE_LIBRARIES
Windows: Switch to the dynamic C runtime This change switches windows to the dynamic C runtime avoiding issues coming from mixing the static and dynamic runtime like the ones outlined in [1] [1] https://developer.blender.org/D5387#122165 Differential Revision: https://developer.blender.org/D6175 Reviewed by: @Sergey
2019-11-08 09:01:00 -07:00
optimized ${OPENIMAGEDENOISE_LIBPATH}/OpenImageDenoise.lib
optimized ${OPENIMAGEDENOISE_LIBPATH}/common.lib
Build: upgrade OpenImageDenoise to 1.2.1 This requires ISPC for building OpenImageDenoise, so that is now added as a dependency as well. Blender itself does not need ISPC for building so it is not included as part of the precompiled libraries. Differential Revision: https://developer.blender.org/D7641
2020-06-25 12:44:39 +02:00
optimized ${OPENIMAGEDENOISE_LIBPATH}/dnnl.lib
Windows: Switch to the dynamic C runtime This change switches windows to the dynamic C runtime avoiding issues coming from mixing the static and dynamic runtime like the ones outlined in [1] [1] https://developer.blender.org/D5387#122165 Differential Revision: https://developer.blender.org/D6175 Reviewed by: @Sergey
2019-11-08 09:01:00 -07:00
debug ${OPENIMAGEDENOISE_LIBPATH}/OpenImageDenoise_d.lib
debug ${OPENIMAGEDENOISE_LIBPATH}/common_d.lib
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
debug ${OPENIMAGEDENOISE_LIBPATH}/dnnl_d.lib
)
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
set(OPENIMAGEDENOISE_DEFINITIONS)
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
if(WITH_ALEMBIC)
set(ALEMBIC ${LIBDIR}/alembic)
set(ALEMBIC_INCLUDE_DIR ${ALEMBIC}/include)
set(ALEMBIC_INCLUDE_DIRS ${ALEMBIC_INCLUDE_DIR})
set(ALEMBIC_LIBPATH ${ALEMBIC}/lib)
Fix T56843 : fix case sensitive filenames on win10 When building with case sensitive folders there were some linker errors.
2019-08-15 09:27:15 -06:00
set(ALEMBIC_LIBRARIES optimized ${ALEMBIC}/lib/Alembic.lib debug ${ALEMBIC}/lib/Alembic_d.lib)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(ALEMBIC_FOUND 1)
endif()
cmake: adjustments required for lib-upgrade on windows.
2018-08-27 19:37:55 -06:00
if(WITH_IMAGE_OPENJPEG)
set(OPENJPEG ${LIBDIR}/openjpeg)
Build: update various libraries for 3.4, fixing bugs and security issues THis is bumping dependencies to fix known CVEs, with the exception of OpenImageIO which also includes bugfixes for performance and correctness with some image types. zlib 1.2.12 -> 1.2.13 freetype 2.11.1 -> 2.12.1 openimageio 2.3.13.0 -> 2.3.20.0 python 3.10.2 -> 3.10.8 openjpeg 2.4.0 -> 2.5.0 ffmpeg 5.0 -> 5.1.2 sndfile 1.0.28 -> 1.1.0 xml2 2.9.10 -> 2.10.3 expat 2.4.4 -> 2.4.9 openssl 1.1.1g/i -> 1.1.1q sqlite 3.31.1 -> 3.37.2 Notable changes: * AOM: the hack we had in place to make it not detect pthreads on windows no longer worked with a more recent cmake version. Disabled pthreads with a diff on Windows. * Python: embedded copy of zlib 2.1.12 swapped out for our 2.1.13 copy with some folder manipulation on Windows. * Freetype: was harbouring a copy of zlib 2.1.12 as well, so that had to end. * FFmpeg: patch used to fix D11796 is no longer needed. Add new patch to deal with simple_idct.asm generating an object file with no sections in it, backport from upstream commit. * TinyXML: still being downloaded but no longer used by OpenColorIO, removed. * GMP applied upstream patch to fix CVE-2021-43618, as there is no release yet. * SQLite and Libsndfile patches no longer needed. Includes contributes by Ray Molenkamp, Campbell Barton and Brecht Van Lommel. Ref T101403 Differential Revision: https://developer.blender.org/D16269
2022-10-20 13:25:54 +02:00
set(OPENJPEG_INCLUDE_DIRS ${OPENJPEG}/include/openjpeg-2.5)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
if(NOT EXISTS "${OPENJPEG_INCLUDE_DIRS}")
Build: update various libraries for 3.4, fixing bugs and security issues THis is bumping dependencies to fix known CVEs, with the exception of OpenImageIO which also includes bugfixes for performance and correctness with some image types. zlib 1.2.12 -> 1.2.13 freetype 2.11.1 -> 2.12.1 openimageio 2.3.13.0 -> 2.3.20.0 python 3.10.2 -> 3.10.8 openjpeg 2.4.0 -> 2.5.0 ffmpeg 5.0 -> 5.1.2 sndfile 1.0.28 -> 1.1.0 xml2 2.9.10 -> 2.10.3 expat 2.4.4 -> 2.4.9 openssl 1.1.1g/i -> 1.1.1q sqlite 3.31.1 -> 3.37.2 Notable changes: * AOM: the hack we had in place to make it not detect pthreads on windows no longer worked with a more recent cmake version. Disabled pthreads with a diff on Windows. * Python: embedded copy of zlib 2.1.12 swapped out for our 2.1.13 copy with some folder manipulation on Windows. * Freetype: was harbouring a copy of zlib 2.1.12 as well, so that had to end. * FFmpeg: patch used to fix D11796 is no longer needed. Add new patch to deal with simple_idct.asm generating an object file with no sections in it, backport from upstream commit. * TinyXML: still being downloaded but no longer used by OpenColorIO, removed. * GMP applied upstream patch to fix CVE-2021-43618, as there is no release yet. * SQLite and Libsndfile patches no longer needed. Includes contributes by Ray Molenkamp, Campbell Barton and Brecht Van Lommel. Ref T101403 Differential Revision: https://developer.blender.org/D16269
2022-10-20 13:25:54 +02:00
# when not found, could be an older lib folder with openjpeg 2.4
# to ease the transition period, fall back if 2.5 is not found.
set(OPENJPEG_INCLUDE_DIRS ${OPENJPEG}/include/openjpeg-2.4)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
endif()
cmake: adjustments required for lib-upgrade on windows.
2018-08-27 19:37:55 -06:00
set(OPENJPEG_LIBRARIES ${OPENJPEG}/lib/openjp2.lib)
endif()
CMake: Remove Cycles specific OpenSubdiv options Just use one flag which enables OpenSubdiv globally for all the areas of Blender.
2018-11-26 11:41:38 +01:00
if(WITH_OPENSUBDIV)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
windows_find_package(OpenSubdiv)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
if(NOT OpenSubdiv_FOUND)
set(OPENSUBDIV ${LIBDIR}/opensubdiv)
set(OPENSUBDIV_INCLUDE_DIRS ${OPENSUBDIV}/include)
set(OPENSUBDIV_LIBPATH ${OPENSUBDIV}/lib)
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
set(OPENSUBDIV_LIBRARIES
optimized ${OPENSUBDIV_LIBPATH}/osdCPU.lib
optimized ${OPENSUBDIV_LIBPATH}/osdGPU.lib
debug ${OPENSUBDIV_LIBPATH}/osdCPU_d.lib
debug ${OPENSUBDIV_LIBPATH}/osdGPU_d.lib
)
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
endif()
if(WITH_SDL)
set(SDL ${LIBDIR}/sdl)
set(SDL_INCLUDE_DIR ${SDL}/include)
set(SDL_LIBPATH ${SDL}/lib)
set(SDL_LIBRARY ${SDL_LIBPATH}/SDL2.lib)
endif()
# Audio IO
if(WITH_SYSTEM_AUDASPACE)
set(AUDASPACE_INCLUDE_DIRS ${LIBDIR}/audaspace/include/audaspace)
set(AUDASPACE_LIBRARIES ${LIBDIR}/audaspace/lib/audaspace.lib)
set(AUDASPACE_C_INCLUDE_DIRS ${LIBDIR}/audaspace/include/audaspace)
set(AUDASPACE_C_LIBRARIES ${LIBDIR}/audaspace/lib/audaspace-c.lib)
set(AUDASPACE_PY_INCLUDE_DIRS ${LIBDIR}/audaspace/include/audaspace)
set(AUDASPACE_PY_LIBRARIES ${LIBDIR}/audaspace/lib/audaspace-py.lib)
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
if(WITH_TBB)
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
windows_find_package(TBB)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
if(NOT TBB_FOUND)
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
set(TBB_LIBRARIES optimized ${LIBDIR}/tbb/lib/tbb.lib debug ${LIBDIR}/tbb/lib/tbb_debug.lib)
set(TBB_INCLUDE_DIR ${LIBDIR}/tbb/include)
set(TBB_INCLUDE_DIRS ${TBB_INCLUDE_DIR})
if(WITH_TBB_MALLOC_PROXY)
set(TBB_MALLOC_LIBRARIES optimized ${LIBDIR}/tbb/lib/tbbmalloc.lib debug ${LIBDIR}/tbb/lib/tbbmalloc_debug.lib)
add_definitions(-DWITH_TBB_MALLOC)
endif()
Add support for the TBB allocator on windows. The heap on windows is single threaded causing it to lag behind linux in performance in allocation heavy multithreaded scenarios, BVH building is a prime example. See https://developer.blender.org/D6218 for benchmark results for testing with the allocator enabled/disabled you can set the environment variable TBB_MALLOC_DISABLE_REPLACEMENT=1 to disable the TBB allocator. Reviewed By: @sergey Differential Revision: https://developer.blender.org/D6218
2019-11-12 20:55:39 -07:00
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
endif()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
# used in many places so include globally, like OpenGL
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 "${PTHREADS_INCLUDE_DIRS}")
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
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
set(WINTAB_INC ${LIBDIR}/wintab/include)
if(WITH_OPENAL)
set(OPENAL ${LIBDIR}/openal)
set(OPENALDIR ${LIBDIR}/openal)
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
set(OPENAL_INCLUDE_DIR ${OPENAL}/include/AL)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENAL_LIBPATH ${OPENAL}/lib)
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
if(MSVC)
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENAL_LIBRARY ${OPENAL_LIBPATH}/openal32.lib)
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
else()
CMake: use only absolute linker paths for msvc. cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
2017-10-29 13:16:22 -06:00
set(OPENAL_LIBRARY ${OPENAL_LIBPATH}/wrap_oal.lib)
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
endif()
endif()
if(WITH_CODEC_SNDFILE)
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
set(LIBSNDFILE ${LIBDIR}/sndfile)
set(LIBSNDFILE_INCLUDE_DIRS ${LIBSNDFILE}/include)
set(LIBSNDFILE_LIBPATH ${LIBSNDFILE}/lib) # TODO, deprecate
Merge branch 'master' into blender2.8 # Conflicts: # build_files/cmake/macros.cmake # build_files/cmake/platform/platform_win32.cmake
2017-10-29 18:20:24 -02:00
set(LIBSNDFILE_LIBRARIES ${LIBSNDFILE_LIBPATH}/libsndfile-1.lib)
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
endif()
Build: clean up handling of some Cycles build options * Don't link embree / OSL when WITH_CYCLES is disabled * Simplify lite config by disabling Cycles as a whole using this * Remove code handling the removed WITH_CYCLES_NETWORK option
2021-12-07 18:31:36 +01:00
if(WITH_CYCLES AND WITH_CYCLES_OSL)
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
set(CYCLES_OSL ${LIBDIR}/osl CACHE PATH "Path to OpenShadingLanguage installation")
Fix: T73830 OSL not finding stdosl.h on linux This extends FindOpenShadingLanguage.cmake to also look for the location of stdosl.h and adds the path to the invocation of oslc to deal with the headers being in different locations a little better. Differential Revision: https://developer.blender.org/D6865 Reviewers: brecht
2020-02-17 10:28:12 -07:00
set(OSL_SHADER_DIR ${CYCLES_OSL}/shaders)
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
# Shaders have moved around a bit between OSL versions, check multiple locations
if(NOT EXISTS "${OSL_SHADER_DIR}")
set(OSL_SHADER_DIR ${CYCLES_OSL}/share/OSL/shaders)
endif()
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
find_library(OSL_LIB_EXEC NAMES oslexec PATHS ${CYCLES_OSL}/lib)
find_library(OSL_LIB_COMP NAMES oslcomp PATHS ${CYCLES_OSL}/lib)
find_library(OSL_LIB_QUERY NAMES oslquery PATHS ${CYCLES_OSL}/lib)
Build: update OSL to version 1.12.6.2 Required changes to make OSL pick up the new oslnoise library. Ref D16269, T101403
2022-10-20 13:33:08 +02:00
find_library(OSL_LIB_NOISE NAMES oslnoise PATHS ${CYCLES_OSL}/lib)
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
find_library(OSL_LIB_EXEC_DEBUG NAMES oslexec_d PATHS ${CYCLES_OSL}/lib)
find_library(OSL_LIB_COMP_DEBUG NAMES oslcomp_d PATHS ${CYCLES_OSL}/lib)
find_library(OSL_LIB_QUERY_DEBUG NAMES oslquery_d PATHS ${CYCLES_OSL}/lib)
Build: update OSL to version 1.12.6.2 Required changes to make OSL pick up the new oslnoise library. Ref D16269, T101403
2022-10-20 13:33:08 +02:00
find_library(OSL_LIB_NOISE_DEBUG NAMES oslnoise_d PATHS ${CYCLES_OSL}/lib)
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 OSL_LIBRARIES
optimized ${OSL_LIB_COMP}
optimized ${OSL_LIB_EXEC}
optimized ${OSL_LIB_QUERY}
debug ${OSL_LIB_EXEC_DEBUG}
debug ${OSL_LIB_COMP_DEBUG}
debug ${OSL_LIB_QUERY_DEBUG}
Deps: PugiXML 1.10 This separates out PugiXML that was previously bundled by OIIO. As this linux/mac libs are not available this commit only contains the builder and windows changes, and the option to enable pugixml is guarded by a platform if, this can be removed once all platforms have committed the svn libs. For details see D8628
2020-11-29 14:01:33 -07:00
${PUGIXML_LIBRARIES}
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
)
Build: update OSL to version 1.12.6.2 Required changes to make OSL pick up the new oslnoise library. Ref D16269, T101403
2022-10-20 13:33:08 +02:00
if(OSL_LIB_NOISE)
list(APPEND OSL_LIBRARIES optimized ${OSL_LIB_NOISE})
endif()
if(OSL_LIB_NOISE_DEBUG)
list(APPEND OSL_LIBRARIES debug ${OSL_LIB_NOISE_DEBUG})
endif()
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
find_path(OSL_INCLUDE_DIR OSL/oslclosure.h PATHS ${CYCLES_OSL}/include)
find_program(OSL_COMPILER NAMES oslc PATHS ${CYCLES_OSL}/bin)
Cycles: Add basic support for using OSL with OptiX This patch generalizes the OSL support in Cycles to include GPU device types and adds an implementation for that in the OptiX device. There are some caveats still, including simplified texturing due to lack of OIIO on the GPU and a few missing OSL intrinsics. Note that this is incomplete and missing an update to the OSL library before being enabled! The implementation is already committed now to simplify further development. Maniphest Tasks: T101222 Differential Revision: https://developer.blender.org/D15902
2022-11-09 14:25:32 +01:00
file(STRINGS "${OSL_INCLUDE_DIR}/OSL/oslversion.h" OSL_LIBRARY_VERSION_MAJOR
REGEX "^[ \t]*#define[ \t]+OSL_LIBRARY_VERSION_MAJOR[ \t]+[0-9]+.*$")
file(STRINGS "${OSL_INCLUDE_DIR}/OSL/oslversion.h" OSL_LIBRARY_VERSION_MINOR
REGEX "^[ \t]*#define[ \t]+OSL_LIBRARY_VERSION_MINOR[ \t]+[0-9]+.*$")
string(REGEX REPLACE ".*#define[ \t]+OSL_LIBRARY_VERSION_MAJOR[ \t]+([.0-9]+).*"
"\\1" OSL_LIBRARY_VERSION_MAJOR ${OSL_LIBRARY_VERSION_MAJOR})
string(REGEX REPLACE ".*#define[ \t]+OSL_LIBRARY_VERSION_MINOR[ \t]+([.0-9]+).*"
"\\1" OSL_LIBRARY_VERSION_MINOR ${OSL_LIBRARY_VERSION_MINOR})
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
endif()
Windows: Enable python debugging in Visual Studio. see D3817 for technical details, and https://wiki.blender.org/wiki/Tools/Debugging/Python_Visual_Studio for a end user quick-start guide. Differential Revision: https://developer.blender.org/D3817
2018-10-22 10:17:08 -06:00
Build: clean up handling of some Cycles build options * Don't link embree / OSL when WITH_CYCLES is disabled * Simplify lite config by disabling Cycles as a whole using this * Remove code handling the removed WITH_CYCLES_NETWORK option
2021-12-07 18:31:36 +01:00
if(WITH_CYCLES AND WITH_CYCLES_EMBREE)
build: add proper embree support to platform_win32.cmake made the use of findpackage optional and add support for debug builds
2018-11-07 19:34:49 -07:00
windows_find_package(Embree)
Cycles: Use USD dependencies when building Hydra render delegate Adds support for linking with some of the dependencies of a USD build instead of the precompiled libraries from Blender, specifically OpenSubdiv, OpenVDB and TBB. Other dependencies keep using the precompiled libraries from Blender, since they are linked statically anyway so it does't matter as much. Plus they have interdependencies that are difficult to resolve when only using selected libraries from the USD build and can't simply assume that USD was built with all of them. This patch also makes building the Hydra render delegate via the standalone repository work and fixes various small issues I ran into in general on Windows (e.g. the use of both fixed paths and `find_package` did not seem to work correctly). Building both the standalone Cycles application and the Hydra render delegate at the same time is supported now as well (the paths in the USD plugin JSON file are updated accordingly). All that needs to be done now to build is to specify a `PXR_ROOT` or `USD_ROOT` CMake variable pointing to the USD installation, everything else is taken care of automatically (CMake targets are loaded from the `pxrTargets.cmake` of USD and linked into the render delegate and OpenSubdiv, OpenVDB and TBB are replaced with those from USD when they exist). Differential Revision: https://developer.blender.org/D14523
2022-03-31 19:27:32 +02:00
if(NOT Embree_FOUND)
build: add proper embree support to platform_win32.cmake made the use of findpackage optional and add support for debug builds
2018-11-07 19:34:49 -07:00
set(EMBREE_INCLUDE_DIRS ${LIBDIR}/embree/include)
set(EMBREE_LIBRARIES
optimized ${LIBDIR}/embree/lib/embree3.lib
optimized ${LIBDIR}/embree/lib/embree_avx2.lib
optimized ${LIBDIR}/embree/lib/embree_avx.lib
optimized ${LIBDIR}/embree/lib/embree_sse42.lib
optimized ${LIBDIR}/embree/lib/lexers.lib
optimized ${LIBDIR}/embree/lib/math.lib
optimized ${LIBDIR}/embree/lib/simd.lib
optimized ${LIBDIR}/embree/lib/sys.lib
optimized ${LIBDIR}/embree/lib/tasking.lib
Cleanup: use 2 space indentation for CMake
2019-04-17 06:35:54 +02:00
build: add proper embree support to platform_win32.cmake made the use of findpackage optional and add support for debug builds
2018-11-07 19:34:49 -07:00
debug ${LIBDIR}/embree/lib/embree3_d.lib
debug ${LIBDIR}/embree/lib/embree_avx2_d.lib
debug ${LIBDIR}/embree/lib/embree_avx_d.lib
debug ${LIBDIR}/embree/lib/embree_sse42_d.lib
debug ${LIBDIR}/embree/lib/lexers_d.lib
debug ${LIBDIR}/embree/lib/math_d.lib
debug ${LIBDIR}/embree/lib/simd_d.lib
debug ${LIBDIR}/embree/lib/sys_d.lib
Cleanup: CMake file indentation
2022-08-09 13:36:45 +10:00
debug ${LIBDIR}/embree/lib/tasking_d.lib
)
build: add proper embree support to platform_win32.cmake made the use of findpackage optional and add support for debug builds
2018-11-07 19:34:49 -07:00
endif()
Cycles: Added Embree as BVH option for CPU renders. Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag. Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly. There, Embree is off by default too and must be enabled with the WITH_EMBREE flag. Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint. TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache). Differential Revision: https://developer.blender.org/D3682
2018-11-07 12:58:12 +01:00
endif()
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
if(WITH_USD)
windows_find_package(USD)
if(NOT USD_FOUND)
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
# 3.5 22.03 libs
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
set(USD_INCLUDE_DIRS ${LIBDIR}/usd/include)
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
set(USD_RELEASE_LIB ${LIBDIR}/usd/lib/usd_usd_ms.lib)
set(USD_DEBUG_LIB ${LIBDIR}/usd/lib/usd_usd_ms_d.lib)
Fix T75357: USD export broken on windows Path to the jsons was wrong so they were not copied
2020-04-06 14:38:52 -06:00
set(USD_LIBRARY_DIR ${LIBDIR}/usd/lib)
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
if(NOT EXISTS "${USD_RELEASE_LIB}") # 3.5 22.11 libs
set(USD_RELEASE_LIB ${LIBDIR}/usd/lib/usd_ms.lib)
set(USD_DEBUG_LIB ${LIBDIR}/usd/lib/usd_ms_d.lib)
endif()
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
# Older USD had different filenames, if the new ones are
# not found see if the older ones exist, to ease the
# transition period while landing libs.
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
if(NOT EXISTS "${USD_RELEASE_LIB}") # 3.3 static libs
set(USD_RELEASE_LIB ${LIBDIR}/usd/lib/usd_usd_m.lib)
set(USD_DEBUG_LIB ${LIBDIR}/usd/lib/usd_usd_m_d.lib)
Build: updates for Blender to build against new 3.2 libraries Building against the existing 3.1 libraries should continue to work, until the precompiled libraries are committed for all platforms. * Enable WebP by default. * Update Windows for new library file names. * Automatically clear outdated CMake cache variables when upgrading to new libraries. * Fix static library linking order issues on Linux for OpenEXR and OpenVDB. Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-04-19 18:09:05 +02:00
endif()
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
set(USD_LIBRARIES
Cleanup: cmake indentation
2020-03-04 10:47:24 +11:00
debug ${USD_DEBUG_LIB}
optimized ${USD_RELEASE_LIB}
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
)
endif()
endif()
Cleanup: style, indentation
2019-06-19 07:24:55 +10:00
if(WINDOWS_PYTHON_DEBUG)
Windows: Enable python debugging in Visual Studio. see D3817 for technical details, and https://wiki.blender.org/wiki/Tools/Debugging/Python_Visual_Studio for a end user quick-start guide. Differential Revision: https://developer.blender.org/D3817
2018-10-22 10:17:08 -06:00
# Include the system scripts in the blender_python_system_scripts project.
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
file(GLOB_RECURSE inFiles "${CMAKE_SOURCE_DIR}/release/scripts/*.*" )
add_custom_target(blender_python_system_scripts SOURCES ${inFiles})
Windows: Enable python debugging in Visual Studio. see D3817 for technical details, and https://wiki.blender.org/wiki/Tools/Debugging/Python_Visual_Studio for a end user quick-start guide. Differential Revision: https://developer.blender.org/D3817
2018-10-22 10:17:08 -06:00
foreach(_source IN ITEMS ${inFiles})
get_filename_component(_source_path "${_source}" PATH)
string(REPLACE "${CMAKE_SOURCE_DIR}/release/scripts/" "" _source_path "${_source_path}")
string(REPLACE "/" "\\" _group_path "${_source_path}")
source_group("${_group_path}" FILES "${_source}")
endforeach()
Cleanup: trailing space
2020-12-11 14:59:08 +11:00
Windows/CMake:Support BLENDER_USER_SCRIPTS in IDE This diff adds support for respecting the `BLENDER_USER_SCRIPTS` environment variable when setting up the IDE environment. Previously the scripts from the users profile folder were always used even when this variable was set, leading to the possibility of the wrong scripts being visible in the IDE. Differential Revision: https://developer.blender.org/D9189 Reviewed By: Ray Molenkamp
2020-10-13 08:45:22 -06:00
# If the user scripts env var is set, include scripts from there otherwise
# include user scripts in the profile folder.
if(DEFINED ENV{BLENDER_USER_SCRIPTS})
message(STATUS "Including user scripts from environment BLENDER_USER_SCRIPTS=$ENV{BLENDER_USER_SCRIPTS}")
set(USER_SCRIPTS_ROOT "$ENV{BLENDER_USER_SCRIPTS}")
else()
message(STATUS "Including user scripts from the profile folder")
# Include the user scripts from the profile folder in the blender_python_user_scripts project.
set(USER_SCRIPTS_ROOT "$ENV{appdata}/blender foundation/blender/${BLENDER_VERSION}/scripts")
endif()
Cleanup: trailing space
2020-12-11 14:59:08 +11:00
Windows: Enable python debugging in Visual Studio. see D3817 for technical details, and https://wiki.blender.org/wiki/Tools/Debugging/Python_Visual_Studio for a end user quick-start guide. Differential Revision: https://developer.blender.org/D3817
2018-10-22 10:17:08 -06:00
file(TO_CMAKE_PATH ${USER_SCRIPTS_ROOT} USER_SCRIPTS_ROOT)
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
file(GLOB_RECURSE inFiles "${USER_SCRIPTS_ROOT}/*.*" )
add_custom_target(blender_python_user_scripts SOURCES ${inFiles})
Windows: Enable python debugging in Visual Studio. see D3817 for technical details, and https://wiki.blender.org/wiki/Tools/Debugging/Python_Visual_Studio for a end user quick-start guide. Differential Revision: https://developer.blender.org/D3817
2018-10-22 10:17:08 -06:00
foreach(_source IN ITEMS ${inFiles})
get_filename_component(_source_path "${_source}" PATH)
Windows/CMake:Support BLENDER_USER_SCRIPTS in IDE This diff adds support for respecting the `BLENDER_USER_SCRIPTS` environment variable when setting up the IDE environment. Previously the scripts from the users profile folder were always used even when this variable was set, leading to the possibility of the wrong scripts being visible in the IDE. Differential Revision: https://developer.blender.org/D9189 Reviewed By: Ray Molenkamp
2020-10-13 08:45:22 -06:00
string(REPLACE "${USER_SCRIPTS_ROOT}" "" _source_path "${_source_path}")
Windows: Enable python debugging in Visual Studio. see D3817 for technical details, and https://wiki.blender.org/wiki/Tools/Debugging/Python_Visual_Studio for a end user quick-start guide. Differential Revision: https://developer.blender.org/D3817
2018-10-22 10:17:08 -06:00
string(REPLACE "/" "\\" _group_path "${_source_path}")
source_group("${_group_path}" FILES "${_source}")
endforeach()
set_target_properties(blender_python_system_scripts PROPERTIES FOLDER "scripts")
set_target_properties(blender_python_user_scripts PROPERTIES FOLDER "scripts")
# Set the default debugging options for the project, only write this file once so the user
# is free to override them at their own perril.
set(USER_PROPS_FILE "${CMAKE_CURRENT_BINARY_DIR}/source/creator/blender.Cpp.user.props")
if(NOT EXISTS ${USER_PROPS_FILE})
# Layout below is messy, because otherwise the generated file will look messy.
file(WRITE ${USER_PROPS_FILE} "<?xml version=\"1.0\" encoding=\"utf-8\"?>
<Project DefaultTargets=\"Build\" xmlns=\"http://schemas.microsoft.com/developer/msbuild/2003\">
<PropertyGroup>
<LocalDebuggerCommandArguments>-con --env-system-scripts \"${CMAKE_SOURCE_DIR}/release/scripts\" </LocalDebuggerCommandArguments>
</PropertyGroup>
</Project>")
endif()
endif()
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(WITH_XR_OPENXR)
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(XR_OPENXR_SDK ${LIBDIR}/xr_openxr_sdk)
set(XR_OPENXR_SDK_LIBPATH ${LIBDIR}/xr_openxr_sdk/lib)
set(XR_OPENXR_SDK_INCLUDE_DIR ${XR_OPENXR_SDK}/include)
# This is the old name of this library, it is checked to
# support the transition between the old and new lib versions
# this can be removed after the next lib update.
if(EXISTS ${XR_OPENXR_SDK_LIBPATH}/openxr_loader_d.lib)
set(XR_OPENXR_SDK_LIBRARIES optimized ${XR_OPENXR_SDK_LIBPATH}/openxr_loader.lib debug ${XR_OPENXR_SDK_LIBPATH}/openxr_loader_d.lib)
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
else()
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(XR_OPENXR_SDK_LIBRARIES optimized ${XR_OPENXR_SDK_LIBPATH}/openxr_loader.lib debug ${XR_OPENXR_SDK_LIBPATH}/openxr_loaderd.lib)
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
endif()
endif()
Deps builder: Add support for building GMP Required for the new boolean code, disabled by default until all platforms have landed the libs and the boolean code actually lands in master. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8384
2020-07-31 09:34:26 -06:00
if(WITH_GMP)
set(GMP_INCLUDE_DIRS ${LIBDIR}/gmp/include)
set(GMP_LIBRARIES ${LIBDIR}/gmp/lib/libgmp-10.lib optimized ${LIBDIR}/gmp/lib/libgmpxx.lib debug ${LIBDIR}/gmp/lib/libgmpxx_d.lib)
set(GMP_ROOT_DIR ${LIBDIR}/gmp)
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(GMP_FOUND ON)
Deps builder: Add support for building GMP Required for the new boolean code, disabled by default until all platforms have landed the libs and the boolean code actually lands in master. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8384
2020-07-31 09:34:26 -06:00
endif()
Deps: Add potrace as a new library dependency For work the GP team plans to land soon (T79877) potrace was taken on as an additional optional dependency. This diff adds building the library to the deps builder and takes care of the integration into the build-system with the `WITH_POTRACE` cmake switch. Differential Revision: https://developer.blender.org/D8662 Reviewed by: brecht, sergey
2020-09-15 13:16:37 -06:00
if(WITH_POTRACE)
set(POTRACE_INCLUDE_DIRS ${LIBDIR}/potrace/include)
set(POTRACE_LIBRARIES ${LIBDIR}/potrace/lib/potrace.lib)
Cleanup: capitalize ON/OFF with CMake
2021-11-04 14:50:24 +11:00
set(POTRACE_FOUND ON)
Deps: Add potrace as a new library dependency For work the GP team plans to land soon (T79877) potrace was taken on as an additional optional dependency. This diff adds building the library to the deps builder and takes care of the integration into the build-system with the `WITH_POTRACE` cmake switch. Differential Revision: https://developer.blender.org/D8662 Reviewed by: brecht, sergey
2020-09-15 13:16:37 -06:00
endif()
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
if(WITH_HARU)
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(HARU_FOUND ON)
set(HARU_ROOT_DIR ${LIBDIR}/haru)
set(HARU_INCLUDE_DIRS ${HARU_ROOT_DIR}/include)
set(HARU_LIBRARIES ${HARU_ROOT_DIR}/lib/libhpdfs.lib)
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
endif()
Add support for Zstandard compression for .blend files Compressing blendfiles can help save a lot of disk space, but the slowdown while loading and saving is a major annoyance. Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there are now several more modern algorithms that outperform it in every way. In this patch, I decided for Zstandard aka Zstd for several reasons: - It is widely supported, both in other programs and libraries as well as in general-purpose compression utilities on Unix - It is extremely flexible - spanning several orders of magnitude of compression speeds depending on the level setting. - It is pretty much on the Pareto frontier for all of its configurations (meaning that no other algorithm is both faster and more efficient). One downside of course is that older versions of Blender will not be able to read these files, but one can always just re-save them without compression or decompress the file manually with an external tool. The implementation here saves additional metadata into the compressed file in order to allow for efficient seeking when loading. This is standard-compliant and will be ignored by other tools that support Zstd. If the metadata is not present (e.g. because you manually compressed a .blend file with another tool), Blender will fall back to sequential reading. Saving is multithreaded to improve performance. Loading is currently not multithreaded since it's not easy to predict the access patterns of the loading code when seeking is supported. In the future, we might want to look into making this more predictable or disabling seeking for the main .blend file, which would then allow for multiple background threads that decompress data ahead of time. The compression level was chosen to get sizes comparable to previous versions at much higher speeds. In the future, this could be exposed as an option. Reviewed By: campbellbarton, brecht, mont29 Differential Revision: https://developer.blender.org/D5799
2021-08-21 03:15:31 +02:00
GHOST: Vulkan Backend. This adds a vulkan backend to GHOST. The code was extracted from the tmp-vulkan branch. The main difference with the original code is that GHOST isn't responsible for fallback. For Metal backend there is already an idea that the GPU module is responsible for the fallback, not the system. For Blender we target Vulkan 1.2 at the time of this patch. MoltenVK (needed to convert Vulkan calls to Metal) has been added as a separate package. This patch isn't useful for end-users, currently when starting blender with `--gpu-backend vulkan` it would crash as the `VBBackend` doesn't initialize the expected global structs in the GPU module. Validated to be working on Windows and Apple. Linux still needs to be tested. Reviewed By: fclem Differential Revision: https://developer.blender.org/D13155
2022-11-22 11:28:37 +01:00
if(WITH_VULKAN_BACKEND)
if(EXISTS ${LIBDIR}/vulkan)
set(VULKAN_FOUND On)
set(VULKAN_ROOT_DIR ${LIBDIR}/vulkan)
set(VULKAN_INCLUDE_DIR ${VULKAN_ROOT_DIR}/include)
set(VULKAN_INCLUDE_DIRS ${VULKAN_INCLUDE_DIR})
set(VULKAN_LIBRARY ${VULKAN_ROOT_DIR}/lib/vulkan-1.lib)
set(VULKAN_LIBRARIES ${VULKAN_LIBRARY})
else()
GPU: Add MoltenVK as dependencies to Vulkan SDK. MoltenVK is part of the vulkan SDK. Blender requires the vulkan SDK to compile. This patch adds the MoltenVK includes and libraries to the Vulkan includes and libraries.
2022-11-22 14:04:36 +01:00
message(WARNING "Vulkan SDK was not found, disabling WITH_VULKAN_BACKEND")
GHOST: Vulkan Backend. This adds a vulkan backend to GHOST. The code was extracted from the tmp-vulkan branch. The main difference with the original code is that GHOST isn't responsible for fallback. For Metal backend there is already an idea that the GPU module is responsible for the fallback, not the system. For Blender we target Vulkan 1.2 at the time of this patch. MoltenVK (needed to convert Vulkan calls to Metal) has been added as a separate package. This patch isn't useful for end-users, currently when starting blender with `--gpu-backend vulkan` it would crash as the `VBBackend` doesn't initialize the expected global structs in the GPU module. Validated to be working on Windows and Apple. Linux still needs to be tested. Reviewed By: fclem Differential Revision: https://developer.blender.org/D13155
2022-11-22 11:28:37 +01:00
set(WITH_VULKAN_BACKEND OFF)
endif()
endif()
Fix OpenPGL and OneAPI being detected by CMake when Cycles is disabled
2022-10-17 13:24:24 +02:00
if(WITH_CYCLES AND WITH_CYCLES_PATH_GUIDING)
Build: integrate OpenPGL into platform files like other libraries To avoid issues with install_deps. If we more generally switch to using CMake configs then perhaps this code can be deduplicated again or at least simplified.
2022-10-04 19:29:52 +02:00
find_package(openpgl QUIET)
if(openpgl_FOUND)
get_target_property(OPENPGL_LIBRARIES_RELEASE openpgl::openpgl LOCATION_RELEASE)
get_target_property(OPENPGL_LIBRARIES_DEBUG openpgl::openpgl LOCATION_DEBUG)
set(OPENPGL_LIBRARIES optimized ${OPENPGL_LIBRARIES_RELEASE} debug ${OPENPGL_LIBRARIES_DEBUG})
get_target_property(OPENPGL_INCLUDE_DIR openpgl::openpgl INTERFACE_INCLUDE_DIRECTORIES)
else()
set(WITH_CYCLES_PATH_GUIDING OFF)
message(STATUS "OpenPGL not found, disabling WITH_CYCLES_PATH_GUIDING")
endif()
endif()
Add support for Zstandard compression for .blend files Compressing blendfiles can help save a lot of disk space, but the slowdown while loading and saving is a major annoyance. Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there are now several more modern algorithms that outperform it in every way. In this patch, I decided for Zstandard aka Zstd for several reasons: - It is widely supported, both in other programs and libraries as well as in general-purpose compression utilities on Unix - It is extremely flexible - spanning several orders of magnitude of compression speeds depending on the level setting. - It is pretty much on the Pareto frontier for all of its configurations (meaning that no other algorithm is both faster and more efficient). One downside of course is that older versions of Blender will not be able to read these files, but one can always just re-save them without compression or decompress the file manually with an external tool. The implementation here saves additional metadata into the compressed file in order to allow for efficient seeking when loading. This is standard-compliant and will be ignored by other tools that support Zstd. If the metadata is not present (e.g. because you manually compressed a .blend file with another tool), Blender will fall back to sequential reading. Saving is multithreaded to improve performance. Loading is currently not multithreaded since it's not easy to predict the access patterns of the loading code when seeking is supported. In the future, we might want to look into making this more predictable or disabling seeking for the main .blend file, which would then allow for multiple background threads that decompress data ahead of time. The compression level was chosen to get sizes comparable to previous versions at much higher speeds. In the future, this could be exposed as an option. Reviewed By: campbellbarton, brecht, mont29 Differential Revision: https://developer.blender.org/D5799
2021-08-21 03:15:31 +02:00
set(ZSTD_INCLUDE_DIRS ${LIBDIR}/zstd/include)
set(ZSTD_LIBRARIES ${LIBDIR}/zstd/lib/zstd_static.lib)
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
Fix OpenPGL and OneAPI being detected by CMake when Cycles is disabled
2022-10-17 13:24:24 +02:00
if(WITH_CYCLES AND WITH_CYCLES_DEVICE_ONEAPI)
Cycles: use direct linking for oneAPI backend This is a minimal set of changes, allowing a lot of cleanup that can happen afterward as it allows sycl method and objects to be used outside of kernel.cpp. Reviewed By: brecht, sergey Differential Revision: https://developer.blender.org/D15397
2022-10-06 18:35:51 +02:00
set(LEVEL_ZERO_ROOT_DIR ${LIBDIR}/level_zero)
set(CYCLES_SYCL ${LIBDIR}/dpcpp CACHE PATH "Path to oneAPI DPC++ compiler")
if(EXISTS ${CYCLES_SYCL} AND NOT SYCL_ROOT_DIR)
set(SYCL_ROOT_DIR ${CYCLES_SYCL})
endif()
Cycles: link oneAPI backend with debug version of sycl when in Debug It fixes SYCL runtime issues in Debug builds that were due to mixing Release and Debug MSVC runtimes. This commit also removes specific handling of dpcpp compiler executable to simplify the CMake implementation. Using it like clang++ works and clang++ executable is also available from Intel oneAPI DPC++ compiler in case it doesn't.
2022-10-06 20:49:53 +02:00
file(GLOB _sycl_runtime_libraries_glob
Cycles: use direct linking for oneAPI backend This is a minimal set of changes, allowing a lot of cleanup that can happen afterward as it allows sycl method and objects to be used outside of kernel.cpp. Reviewed By: brecht, sergey Differential Revision: https://developer.blender.org/D15397
2022-10-06 18:35:51 +02:00
${SYCL_ROOT_DIR}/bin/sycl.dll
${SYCL_ROOT_DIR}/bin/sycl[0-9].dll
)
Cycles: link oneAPI backend with debug version of sycl when in Debug It fixes SYCL runtime issues in Debug builds that were due to mixing Release and Debug MSVC runtimes. This commit also removes specific handling of dpcpp compiler executable to simplify the CMake implementation. Using it like clang++ works and clang++ executable is also available from Intel oneAPI DPC++ compiler in case it doesn't.
2022-10-06 20:49:53 +02:00
foreach(sycl_runtime_library IN LISTS _sycl_runtime_libraries_glob)
string(REPLACE ".dll" "$<$<CONFIG:Debug>:d>.dll" sycl_runtime_library ${sycl_runtime_library})
list(APPEND _sycl_runtime_libraries ${sycl_runtime_library})
endforeach()
unset(_sycl_runtime_libraries_glob)
Cycles: Improve oneAPI backend support for non-Intel platforms
2022-11-25 15:43:40 +01:00
file(GLOB _sycl_pi_runtime_libraries_glob
${SYCL_ROOT_DIR}/bin/pi_*.dll
)
list(REMOVE_ITEM _sycl_pi_runtime_libraries_glob "${SYCL_ROOT_DIR}/bin/pi_opencl.dll")
Cleanup: cmake formatting
2022-12-17 13:30:07 +11:00
list(APPEND _sycl_runtime_libraries ${_sycl_pi_runtime_libraries_glob})
Cycles: Improve oneAPI backend support for non-Intel platforms
2022-11-25 15:43:40 +01:00
unset(_sycl_pi_runtime_libraries_glob)
Cycles: use direct linking for oneAPI backend This is a minimal set of changes, allowing a lot of cleanup that can happen afterward as it allows sycl method and objects to be used outside of kernel.cpp. Reviewed By: brecht, sergey Differential Revision: https://developer.blender.org/D15397
2022-10-06 18:35:51 +02:00
list(APPEND PLATFORM_BUNDLED_LIBRARIES ${_sycl_runtime_libraries})
unset(_sycl_runtime_libraries)
endif()
Build: make running executables as part of build/tests work with shared libs Ensure the environment is set up for blender_test, idiff and oslc so that they can find the required shared libraries. Also deduplicate add_bundled_libraries() between Linux and macOS. Includes contributions by Ray Molenkamp and Brecht Van Lommel. Ref T99618
2022-12-05 23:05:25 +01:00
# Environment variables to run precompiled executables that needed libraries.
list(JOIN PLATFORM_BUNDLED_LIBRARY_DIRS ";" _library_paths)
set(PLATFORM_ENV_BUILD_DIRS "${LIBDIR}/OpenImageIO/bin\;${LIBDIR}/boost/lib\;${LIBDIR}/openexr/bin\;${LIBDIR}/imath/bin\;${PATH}")
set(PLATFORM_ENV_BUILD "PATH=${PLATFORM_ENV_BUILD_DIRS}")
# Install needs the additional folders from PLATFORM_ENV_BUILD_DIRS as well, as tools like idiff and abcls use the release mode dlls
set(PLATFORM_ENV_INSTALL "PATH=${CMAKE_INSTALL_PREFIX_WITH_CONFIG}/blender.shared/\;${PLATFORM_ENV_BUILD_DIRS}\;$ENV{PATH}")
unset(_library_paths)
Copy Permalink