summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuild.cmake
diff options
context:
space:
mode:
authorAlexandru Croitor <alexandru.croitor@qt.io>2020-07-24 18:00:21 +0200
committerAlexandru Croitor <alexandru.croitor@qt.io>2020-07-29 17:33:14 +0200
commit7b9904849fe1a43f0db8216076a9e974ebca5c78 (patch)
tree3a832c3e9cf89d9dcc806effdd6ddf9cf6402965 /cmake/QtBuild.cmake
parent071fc289c407d2cbdcf6fc66504d6ad536ad9216 (diff)
CMake: Fix _nolink targets to be optional on the consumer side
On Windows, if Qt is built with Vulkan support but the user's machine does not have Vulkan, it should still be possible to configure and build an application (if the application does not use Vulkan of course). When Qt is built with qmake, the special windows_vulkan_sdk.prf file makes sure not to export build time Vulkan include headers into the generated .pri files. The same file also tries to find the include headers via an environment variable. If it isn't set, it just adds a bogus "/include" include path, which doesn't fail a user's application build. This wasn't the case for an application built with CMake, because the exported Vulkan_nolink target uncodinitionally referenced Vulkan's target properties. Which means that if the Vulkan package was not found, the application failed to configure. To mimic qmake's behavior, make sure to query the target properties only if the Vulkan target exists, via the TARGET_EXISTS generator expression. Apply the same logic to all _nolink targets. This might not be entirely correct in all cases, but we can revise this behavior later after more feedback. At the very least it allows building non-Vulkan based applications. Task-number: QTBUG-85240 Change-Id: Iffbb03a84e8637ed54d0811433e66fe6de43d71f Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Diffstat (limited to 'cmake/QtBuild.cmake')
-rw-r--r--cmake/QtBuild.cmake31
1 files changed, 20 insertions, 11 deletions
diff --git a/cmake/QtBuild.cmake b/cmake/QtBuild.cmake
index e9a6ead01b..9c5161f961 100644
--- a/cmake/QtBuild.cmake
+++ b/cmake/QtBuild.cmake
@@ -1598,17 +1598,26 @@ function(qt_create_nolink_target target dependee_target)
if(NOT TARGET "${nolink_target}")
add_library("${nolink_target}" INTERFACE)
set(prefixed_nolink_target "${target}_nolink")
- set_target_properties("${nolink_target}" PROPERTIES
- INTERFACE_INCLUDE_DIRECTORIES
- $<TARGET_PROPERTY:${target},INTERFACE_INCLUDE_DIRECTORIES>
- INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
- $<TARGET_PROPERTY:${target},INTERFACE_SYSTEM_INCLUDE_DIRECTORIES>
- INTERFACE_COMPILE_DEFINITIONS
- $<TARGET_PROPERTY:${target},INTERFACE_COMPILE_DEFINITIONS>
- INTERFACE_COMPILE_OPTIONS
- $<TARGET_PROPERTY:${target},INTERFACE_COMPILE_OPTIONS>
- INTERFACE_COMPILE_FEATURES
- $<TARGET_PROPERTY:${target},INTERFACE_COMPILE_FEATURES>)
+
+ # Whe configuring an example with qmake, if QtGui is built with Vulkan support but the
+ # user's machine where Qt is installed doesn't have Vulkan, qmake doesn't fail saying
+ # that vulkan is not installed. Instead it silently configures and just doesn't add
+ # the include headers.
+ # To mimic that in CMake, if the Vulkan CMake package is not found, we shouldn't fail
+ # at generation time saying that the Vulkan target does not exist. Instead check with a
+ # genex that the target exists to query the properties, otherwise just silently continue.
+ # FIXME: If we figure out that such behavior should only be applied to Vulkan, and not the
+ # other _nolink targets, we'll have to modify this to be configurable.
+ set(target_exists_genex "$<TARGET_EXISTS:${target}>")
+ set(props_to_set INTERFACE_INCLUDE_DIRECTORIES INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
+ INTERFACE_COMPILE_DEFINITIONS INTERFACE_COMPILE_OPTIONS
+ INTERFACE_COMPILE_FEATURES)
+ foreach(prop ${props_to_set})
+ set_target_properties(
+ "${nolink_target}" PROPERTIES
+ ${prop} $<${target_exists_genex}:$<TARGET_PROPERTY:${target},${prop}>>
+ )
+ endforeach()
add_library(${prefixed_nolink_target} ALIAS ${nolink_target})
add_library("${INSTALL_CMAKE_NAMESPACE}::${nolink_target}" ALIAS ${nolink_target})