This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/build_files/cmake/platform/platform_apple.cmake

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

508 lines
15 KiB
CMake
Raw Permalink Normal View History

# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright 2016 Blender Foundation. All rights reserved.
# Libraries configuration for Apple.
macro(find_package_wrapper)
# do nothing, just satisfy the macro
endmacro()
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
function(print_found_status
lib_name
lib_path
)
if(FIRST_RUN)
if(lib_path)
message(STATUS "Found ${lib_name}: ${lib_path}")
else()
message(WARNING "Could NOT find ${lib_name}")
endif()
endif()
endfunction()
# ------------------------------------------------------------------------
# Find system provided libraries.
# Find system ZLIB, not the pre-compiled one supplied with OpenCollada.
set(ZLIB_ROOT /usr)
find_package(ZLIB REQUIRED)
find_package(BZip2 REQUIRED)
list(APPEND ZLIB_LIBRARIES ${BZIP2_LIBRARIES})
if(WITH_OPENAL)
find_package(OpenAL)
if(NOT OPENAL_FOUND)
message(WARNING "OpenAL not found, disabling WITH_OPENAL")
set(WITH_OPENAL OFF)
endif()
endif()
if(WITH_JACK)
find_library(JACK_FRAMEWORK
NAMES jackmp
)
if(NOT JACK_FRAMEWORK)
message(STATUS "JACK not found, disabling WITH_JACK")
set(WITH_JACK OFF)
else()
set(JACK_INCLUDE_DIRS ${JACK_FRAMEWORK}/headers)
endif()
endif()
if(NOT DEFINED LIBDIR)
if("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "x86_64")
set(LIBDIR ${CMAKE_SOURCE_DIR}/../lib/darwin)
else()
set(LIBDIR ${CMAKE_SOURCE_DIR}/../lib/darwin_${CMAKE_OSX_ARCHITECTURES})
endif()
else()
message(STATUS "Using pre-compiled LIBDIR: ${LIBDIR}")
endif()
if(NOT EXISTS "${LIBDIR}/")
message(FATAL_ERROR "Mac OSX requires pre-compiled libs at: '${LIBDIR}'")
endif()
# Prefer lib directory paths
file(GLOB LIB_SUBDIRS ${LIBDIR}/*)
set(CMAKE_PREFIX_PATH ${LIB_SUBDIRS})
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
# -------------------------------------------------------------------------
# Find precompiled libraries, and avoid system or user-installed ones.
if(EXISTS ${LIBDIR})
without_system_libs_begin()
endif()
if(WITH_ALEMBIC)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(Alembic)
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)
find_package(USD)
if(NOT USD_FOUND)
message(STATUS "USD not found, disabling WITH_USD")
set(WITH_USD OFF)
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
endif()
if(WITH_OPENSUBDIV)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(OpenSubdiv)
endif()
if(WITH_CODEC_SNDFILE)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(SndFile)
find_library(_sndfile_FLAC_LIBRARY NAMES flac HINTS ${LIBDIR}/sndfile/lib)
find_library(_sndfile_OGG_LIBRARY NAMES ogg HINTS ${LIBDIR}/ffmpeg/lib)
find_library(_sndfile_VORBIS_LIBRARY NAMES vorbis HINTS ${LIBDIR}/ffmpeg/lib)
find_library(_sndfile_VORBISENC_LIBRARY NAMES vorbisenc HINTS ${LIBDIR}/ffmpeg/lib)
list(APPEND LIBSNDFILE_LIBRARIES
${_sndfile_FLAC_LIBRARY}
${_sndfile_OGG_LIBRARY}
${_sndfile_VORBIS_LIBRARY}
${_sndfile_VORBISENC_LIBRARY}
)
print_found_status("SndFile libraries" "${LIBSNDFILE_LIBRARIES}")
unset(_sndfile_FLAC_LIBRARY)
unset(_sndfile_OGG_LIBRARY)
unset(_sndfile_VORBIS_LIBRARY)
unset(_sndfile_VORBISENC_LIBRARY)
endif()
if(WITH_PYTHON)
2022-01-27 15:03:11 +01:00
# Use precompiled libraries by default.
set(PYTHON_VERSION 3.10)
if(NOT WITH_PYTHON_MODULE AND NOT WITH_PYTHON_FRAMEWORK)
2022-01-27 15:03:11 +01:00
# Normally cached but not since we include them with blender.
set(PYTHON_INCLUDE_DIR "${LIBDIR}/python/include/python${PYTHON_VERSION}")
set(PYTHON_EXECUTABLE "${LIBDIR}/python/bin/python${PYTHON_VERSION}")
set(PYTHON_LIBRARY ${LIBDIR}/python/lib/libpython${PYTHON_VERSION}.a)
set(PYTHON_LIBPATH "${LIBDIR}/python/lib/python${PYTHON_VERSION}")
else()
2022-01-27 15:03:11 +01:00
# Module must be compiled against Python framework.
set(_py_framework "/Library/Frameworks/Python.framework/Versions/${PYTHON_VERSION}")
set(PYTHON_INCLUDE_DIR "${_py_framework}/include/python${PYTHON_VERSION}")
set(PYTHON_EXECUTABLE "${_py_framework}/bin/python${PYTHON_VERSION}")
set(PYTHON_LIBPATH "${_py_framework}/lib/python${PYTHON_VERSION}")
unset(_py_framework)
endif()
# uncached vars
set(PYTHON_INCLUDE_DIRS "${PYTHON_INCLUDE_DIR}")
set(PYTHON_LIBRARIES "${PYTHON_LIBRARY}")
# needed for Audaspace, numpy is installed into python site-packages
set(PYTHON_NUMPY_INCLUDE_DIRS "${PYTHON_LIBPATH}/site-packages/numpy/core/include")
if(NOT EXISTS "${PYTHON_EXECUTABLE}")
message(FATAL_ERROR "Python executable missing: ${PYTHON_EXECUTABLE}")
endif()
endif()
if(WITH_FFTW3)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(Fftw3)
endif()
# FreeType compiled with Brotli compression for woff2.
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(Freetype REQUIRED)
list(APPEND FREETYPE_LIBRARIES
${LIBDIR}/brotli/lib/libbrotlicommon-static.a
${LIBDIR}/brotli/lib/libbrotlidec-static.a)
if(WITH_IMAGE_OPENEXR)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(OpenEXR)
endif()
if(WITH_CODEC_FFMPEG)
set(FFMPEG_ROOT_DIR ${LIBDIR}/ffmpeg)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
set(FFMPEG_FIND_COMPONENTS
avcodec avdevice avformat avutil
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
mp3lame ogg opus swresample swscale
theora theoradec theoraenc vorbis vorbisenc
vorbisfile vpx x264 xvidcore)
find_package(FFmpeg)
endif()
2017-10-24 13:09:41 +02:00
if(WITH_IMAGE_OPENJPEG OR WITH_CODEC_FFMPEG)
# use openjpeg from libdir that is linked into ffmpeg
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(OpenJPEG)
endif()
find_library(SYSTEMSTUBS_LIBRARY
NAMES
SystemStubs
PATHS
)
mark_as_advanced(SYSTEMSTUBS_LIBRARY)
if(SYSTEMSTUBS_LIBRARY)
list(APPEND PLATFORM_LINKLIBS SystemStubs)
endif()
string(APPEND PLATFORM_CFLAGS " -pipe -funsigned-char -fno-strict-aliasing")
set(PLATFORM_LINKFLAGS
"-fexceptions -framework CoreServices -framework Foundation -framework IOKit -framework AppKit -framework Cocoa -framework Carbon -framework AudioUnit -framework AudioToolbox -framework CoreAudio -framework Metal -framework QuartzCore"
)
list(APPEND PLATFORM_LINKLIBS c++)
if(WITH_OPENIMAGEDENOISE)
if("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "arm64")
# OpenImageDenoise uses BNNS from the Accelerate framework.
string(APPEND PLATFORM_LINKFLAGS " -framework Accelerate")
endif()
endif()
if(WITH_JACK)
string(APPEND PLATFORM_LINKFLAGS " -F/Library/Frameworks -weak_framework jackmp")
endif()
if(WITH_PYTHON_MODULE OR WITH_PYTHON_FRAMEWORK)
# force cmake to link right framework
string(APPEND PLATFORM_LINKFLAGS " /Library/Frameworks/Python.framework/Versions/${PYTHON_VERSION}/Python")
endif()
if(WITH_OPENCOLLADA)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(OpenCOLLADA)
find_library(PCRE_LIBRARIES NAMES pcre HINTS ${LIBDIR}/opencollada/lib)
find_library(XML2_LIBRARIES NAMES xml2 HINTS ${LIBDIR}/opencollada/lib)
print_found_status("PCRE" "${PCRE_LIBRARIES}")
print_found_status("XML2" "${XML2_LIBRARIES}")
endif()
if(WITH_SDL)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(SDL2)
set(SDL_INCLUDE_DIR ${SDL2_INCLUDE_DIRS})
set(SDL_LIBRARY ${SDL2_LIBRARIES})
string(APPEND PLATFORM_LINKFLAGS " -framework ForceFeedback")
endif()
set(PNG_ROOT ${LIBDIR}/png)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(PNG REQUIRED)
set(JPEG_ROOT ${LIBDIR}/jpeg)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(JPEG REQUIRED)
if(WITH_IMAGE_TIFF)
set(TIFF_ROOT ${LIBDIR}/tiff)
find_package(TIFF)
if(NOT TIFF_FOUND)
message(WARNING "TIFF not found, disabling WITH_IMAGE_TIFF")
set(WITH_IMAGE_TIFF OFF)
endif()
endif()
if(WITH_IMAGE_WEBP)
set(WEBP_ROOT_DIR ${LIBDIR}/webp)
find_package(WebP)
if(NOT WEBP_FOUND)
message(WARNING "WebP not found, disabling WITH_IMAGE_WEBP")
set(WITH_IMAGE_WEBP OFF)
endif()
endif()
if(WITH_BOOST)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
set(Boost_NO_BOOST_CMAKE ON)
set(BOOST_ROOT ${LIBDIR}/boost)
set(Boost_NO_SYSTEM_PATHS ON)
set(_boost_FIND_COMPONENTS date_time filesystem regex system thread wave)
if(WITH_INTERNATIONAL)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
list(APPEND _boost_FIND_COMPONENTS locale)
endif()
if(WITH_OPENVDB)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
list(APPEND _boost_FIND_COMPONENTS iostreams)
endif()
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(Boost COMPONENTS ${_boost_FIND_COMPONENTS})
set(BOOST_LIBRARIES ${Boost_LIBRARIES})
set(BOOST_INCLUDE_DIR ${Boost_INCLUDE_DIRS})
set(BOOST_DEFINITIONS)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
mark_as_advanced(Boost_LIBRARIES)
mark_as_advanced(Boost_INCLUDE_DIRS)
unset(_boost_FIND_COMPONENTS)
endif()
if(WITH_INTERNATIONAL OR WITH_CODEC_FFMPEG)
string(APPEND PLATFORM_LINKFLAGS " -liconv") # boost_locale and ffmpeg needs it !
endif()
if(WITH_PUGIXML)
find_package(PugiXML)
if(NOT PUGIXML_FOUND)
message(WARNING "PugiXML not found, disabling WITH_PUGIXML")
set(WITH_PUGIXML OFF)
endif()
endif()
if(WITH_OPENIMAGEIO)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(OpenImageIO)
list(APPEND OPENIMAGEIO_LIBRARIES
${PNG_LIBRARIES}
${JPEG_LIBRARIES}
${TIFF_LIBRARY}
${OPENEXR_LIBRARIES}
2017-10-24 13:09:41 +02:00
${OPENJPEG_LIBRARIES}
${ZLIB_LIBRARIES}
)
set(OPENIMAGEIO_DEFINITIONS "-DOIIO_STATIC_BUILD")
set(OPENIMAGEIO_IDIFF "${LIBDIR}/openimageio/bin/idiff")
endif()
if(WITH_OPENCOLORIO)
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 19:35:00 +01:00
find_package(OpenColorIO 2.0.0)
if(NOT OPENCOLORIO_FOUND)
set(WITH_OPENCOLORIO OFF)
message(STATUS "OpenColorIO not found, disabling WITH_OPENCOLORIO")
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 19:35:00 +01:00
endif()
endif()
if(WITH_OPENVDB)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(OpenVDB)
find_library(BLOSC_LIBRARIES NAMES blosc HINTS ${LIBDIR}/openvdb/lib)
print_found_status("Blosc" "${BLOSC_LIBRARIES}")
list(APPEND OPENVDB_LIBRARIES ${BLOSC_LIBRARIES})
set(OPENVDB_DEFINITIONS)
endif()
if(WITH_NANOVDB)
find_package(NanoVDB)
endif()
if(WITH_CPU_SIMD AND SUPPORT_NEON_BUILD)
find_package(sse2neon)
endif()
if(WITH_LLVM)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
find_package(LLVM)
if(NOT LLVM_FOUND)
message(FATAL_ERROR "LLVM not found.")
endif()
if(WITH_CLANG)
find_package(Clang)
if(NOT CLANG_FOUND)
message(FATAL_ERROR "Clang not found.")
endif()
endif()
endif()
if(WITH_CYCLES AND WITH_CYCLES_OSL)
set(CYCLES_OSL ${LIBDIR}/osl)
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)
# WARNING! depends on correct order of OSL libs linking
list(APPEND OSL_LIBRARIES ${OSL_LIB_COMP} -force_load ${OSL_LIB_EXEC} ${OSL_LIB_QUERY})
find_path(OSL_INCLUDE_DIR OSL/oslclosure.h PATHS ${CYCLES_OSL}/include)
find_program(OSL_COMPILER NAMES oslc PATHS ${CYCLES_OSL}/bin)
find_path(OSL_SHADER_DIR NAMES stdosl.h PATHS ${CYCLES_OSL}/share/OSL/shaders)
if(OSL_INCLUDE_DIR AND OSL_LIBRARIES AND OSL_COMPILER AND OSL_SHADER_DIR)
set(OSL_FOUND TRUE)
else()
message(WARNING "OSL not found, disabling WITH_CYCLES_OSL")
set(WITH_CYCLES_OSL OFF)
endif()
endif()
if(WITH_CYCLES AND WITH_CYCLES_EMBREE)
find_package(Embree 3.8.0 REQUIRED)
# Increase stack size for Embree, only works for executables.
if(NOT WITH_PYTHON_MODULE)
string(APPEND PLATFORM_LINKFLAGS " -Wl,-stack_size,0x100000")
endif()
# Embree static library linking can mix up SSE and AVX symbols, causing
# crashes on macOS systems with older CPUs that don't have AVX. Using
# force load avoids that. The Embree shared library does not suffer from
# this problem, precisely because linking a shared library uses force load.
set(_embree_libraries_force_load)
foreach(_embree_library ${EMBREE_LIBRARIES})
list(APPEND _embree_libraries_force_load "-Wl,-force_load,${_embree_library}")
endforeach()
set(EMBREE_LIBRARIES ${_embree_libraries_force_load})
endif()
if(WITH_OPENIMAGEDENOISE)
find_package(OpenImageDenoise)
if(NOT OPENIMAGEDENOISE_FOUND)
set(WITH_OPENIMAGEDENOISE OFF)
message(STATUS "OpenImageDenoise not found, disabling WITH_OPENIMAGEDENOISE")
endif()
endif()
if(WITH_TBB)
find_package(TBB)
2021-06-16 00:02:39 +10:00
if(NOT TBB_FOUND)
message(WARNING "TBB not found, disabling WITH_TBB")
set(WITH_TBB OFF)
endif()
endif()
if(WITH_POTRACE)
find_package(Potrace)
if(NOT POTRACE_FOUND)
message(WARNING "potrace not found, disabling WITH_POTRACE")
set(WITH_POTRACE OFF)
endif()
endif()
# CMake FindOpenMP doesn't know about AppleClang before 3.12, so provide custom flags.
if(WITH_OPENMP)
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
# Use OpenMP from our precompiled libraries.
message(STATUS "Using ${LIBDIR}/openmp for OpenMP")
set(OPENMP_CUSTOM ON)
set(OPENMP_FOUND ON)
set(OpenMP_C_FLAGS "-Xclang -fopenmp -I'${LIBDIR}/openmp/include'")
set(OpenMP_CXX_FLAGS "-Xclang -fopenmp -I'${LIBDIR}/openmp/include'")
set(OpenMP_LIBRARY_DIR "${LIBDIR}/openmp/lib/")
set(OpenMP_LINKER_FLAGS "-L'${OpenMP_LIBRARY_DIR}' -lomp")
set(OpenMP_LIBRARY "${OpenMP_LIBRARY_DIR}/libomp.dylib")
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)
find_package(XR_OpenXR_SDK)
if(NOT XR_OPENXR_SDK_FOUND)
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
message(WARNING "OpenXR-SDK was not found, disabling WITH_XR_OPENXR")
set(WITH_XR_OPENXR OFF)
endif()
endif()
if(WITH_GMP)
find_package(GMP)
if(NOT GMP_FOUND)
message(WARNING "GMP not found, disabling WITH_GMP")
set(WITH_GMP OFF)
endif()
endif()
if(WITH_HARU)
find_package(Haru)
if(NOT HARU_FOUND)
message(WARNING "Haru not found, disabling WITH_HARU")
set(WITH_HARU OFF)
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_ROOT_DIR ${LIBDIR}/zstd)
find_package(Zstd REQUIRED)
CMake/macOS: Remove _LIBPATH, avoid link_directories. After tests were bundled in a single executable and cycles and libmv created their own tests, the warnings on macOS have gone over 800. The reason is setting `*_LIBRARIES` to names of the libraries and later using `link_directories` to link them properly. https://cmake.org/cmake/help/latest/command/link_directories.html > Note This command is rarely necessary and should be avoided where > there are other choices. Prefer to pass full absolute paths to > libraries where possible, since this ensures the correct library > will always be linked. The find_library() command provides the > full path, which can generally be used directly in calls to > target_link_libraries(). Warnings like the following popup for every target/executable, for every library it links to. ``` ld: warning: directory not found for option '-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug' ``` The patch completes a step towards removing `link_directories` as mentioned in TODO at several places. The patch uses absolute paths to link libraries and removes all `*_LIBPATH`s except `PYTHON_LIBPATH` from `platform_apple.cmake` file. (The corner case where it's used seems like dead code. Python is no longer shipped with that file structure.) Also, unused code for LLVM-3.4 has been removed. Also, guards to avoid searching libraries in system directories have been added. `APPLE` platform now no longer needs `setup_libdirs`, `cycles_link_directories`, and `link_directories`. The number of warnings now is less than 100, most of them being deprecation ones in dependencies. This patch depended on {rBb746179d0add}, {rB2fdbe4d05011}, {rB402a4cadba49} and {rBd7f482f88ecb}. Reviewed By: brecht Differential Revision: https://developer.blender.org/D8855
2020-10-08 19:31:40 +05:30
if(EXISTS ${LIBDIR})
without_system_libs_end()
endif()
# ---------------------------------------------------------------------
# Set compiler and linker flags.
set(EXETYPE MACOSX_BUNDLE)
set(CMAKE_C_FLAGS_DEBUG "-g")
set(CMAKE_CXX_FLAGS_DEBUG "-g")
if(CMAKE_OSX_ARCHITECTURES MATCHES "x86_64" OR CMAKE_OSX_ARCHITECTURES MATCHES "i386")
set(CMAKE_CXX_FLAGS_RELEASE "-O2 -mdynamic-no-pic -msse -msse2 -msse3 -mssse3")
set(CMAKE_C_FLAGS_RELEASE "-O2 -mdynamic-no-pic -msse -msse2 -msse3 -mssse3")
if(NOT CMAKE_C_COMPILER_ID MATCHES "Clang")
string(APPEND CMAKE_C_FLAGS_RELEASE " -ftree-vectorize -fvariable-expansion-in-unroller")
string(APPEND CMAKE_CXX_FLAGS_RELEASE " -ftree-vectorize -fvariable-expansion-in-unroller")
endif()
else()
set(CMAKE_C_FLAGS_RELEASE "-O2 -mdynamic-no-pic")
set(CMAKE_CXX_FLAGS_RELEASE "-O2 -mdynamic-no-pic")
endif()
# Clang has too low template depth of 128 for libmv.
string(APPEND CMAKE_CXX_FLAGS " -ftemplate-depth=1024")
# Avoid conflicts with Luxrender, and other plug-ins that may use the same
# libraries as Blender with a different version or build options.
string(APPEND PLATFORM_LINKFLAGS
" -Wl,-unexported_symbols_list,'${CMAKE_SOURCE_DIR}/source/creator/osx_locals.map'"
)
string(APPEND CMAKE_CXX_FLAGS " -stdlib=libc++")
string(APPEND PLATFORM_LINKFLAGS " -stdlib=libc++")
# Suppress ranlib "has no symbols" warnings (workaround for T48250)
set(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> Scr <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> Scr <TARGET> <LINK_FLAGS> <OBJECTS>")
# llvm-ranlib doesn't support this flag. Xcode's libtool does.
if(NOT ${CMAKE_RANLIB} MATCHES ".*llvm-ranlib$")
set(CMAKE_C_ARCHIVE_FINISH "<CMAKE_RANLIB> -no_warning_for_no_symbols -c <TARGET>")
set(CMAKE_CXX_ARCHIVE_FINISH "<CMAKE_RANLIB> -no_warning_for_no_symbols -c <TARGET>")
endif()
if(WITH_COMPILER_CCACHE)
if(NOT CMAKE_GENERATOR STREQUAL "Xcode")
find_program(CCACHE_PROGRAM ccache)
if(CCACHE_PROGRAM)
# Makefiles and ninja
set(CMAKE_C_COMPILER_LAUNCHER "${CCACHE_PROGRAM}" CACHE STRING "" FORCE)
set(CMAKE_CXX_COMPILER_LAUNCHER "${CCACHE_PROGRAM}" CACHE STRING "" FORCE)
else()
message(WARNING "Ccache NOT found, disabling WITH_COMPILER_CCACHE")
set(WITH_COMPILER_CCACHE OFF)
endif()
endif()
endif()
# For binaries that are built but not installed (also not distributed) (datatoc,
# makesdna, tests, etc.), we add an rpath to the OpenMP library dir through
# CMAKE_BUILD_RPATH. This avoids having to make many copies of the dylib next to each binary.
#
# For the installed Python module and installed Blender executable, CMAKE_INSTALL_RPATH
# is modified to find the dylib in an adjacent folder. Install step puts the libraries there.
set(CMAKE_SKIP_BUILD_RPATH FALSE)
list(APPEND CMAKE_BUILD_RPATH "${OpenMP_LIBRARY_DIR}")
set(CMAKE_SKIP_INSTALL_RPATH FALSE)
list(APPEND CMAKE_INSTALL_RPATH "@loader_path/../Resources/${BLENDER_VERSION}/lib")
# Same as `CFBundleIdentifier` in Info.plist.
set(CMAKE_XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER "org.blenderfoundation.blender")