The current released versions of clang-cl does not work with CMakes
module implementation. Rather than break downstream users, just disable
the module support for the time being.
17.10 and before has a bug that prevents the vulkan.cppm module from
compiling. The module support wont be enabled unless the MSVC version
contains the fix.
Adds the VULKAN_HEADERS_ENABLE_MODULE option to control whether to build the Vulkan-Hpp module.
This is necessary to allow CI to pass while waiting for the MSVC version 17.11, which fixes an
internal compiler bug, to be added to github actions runners.
Installing a C++ module in CMake isn't something which is well defined currently.
Rather than add code which behaves poorly or flat out wrong, it is better to not
try to install a binary module for the time being. The vulkan.cppm file is still
included in the install so downstream users can still create a module from it.
- Guarded behind `if()` version and compiler test
- Linked to `Vulkan-Headers` as a dependency
- Also added `CXX` to the `LANGUAGES` property of the project
VULKAN_HEADERS_INSTALL was added since it was believed there was
a valid use case for it.
After looking into the use case that provoked this change there is
no reason to keep VULKAN_HEADERS_INSTALL as an option.
Here is the use case we do NOT want to support:
https://github.com/KhronosGroup/Vulkan-Headers/pull/416#issuecomment-1622318949
Fundamentally this problem is caused add_subdirectory/find_package
not being able to work together flawlessly.
Which isn't the responsibility of Vulkan-Headers to fix.
It's the responsibility of projects that consume Vulkan-Headers
to account for either method.
As described by the CMake maintainers:
https://discourse.cmake.org/t/idiomatic-way-to-handle-packages-and-add-subdirectory/8400
Vulkan::Registry behaves differently in `add_subdirectory` vs
`find_package` builds. Which can result in build failures.
Also Vulkan::Registry never made sense as a CMake target and
was very brittle in numerous ways.
Better to provide a `VULKAN_HEADERS_REGISTRY_DIRECTORY` to users
instead and remove Vulkan::Registry completely.
closes#351
When trying to update the version of Vulkan-Headers used in Dawn/Tint,
I encountered errors like this:
Target "Vulkan-Headers" contains relative path in its
INTERFACE_INCLUDE_DIRECTORIES:
""/home/foo/workspace/dawn/third_party/vulkan-deps/vulkan-headers/src/include""
This PR removes the offending quotes
Now as part of install 2 files are created:
- VulkanHeadersConfig.cmake
- VulkanHeadersConfigVersion.cmake
This allows usage of find_package
closes#157
Generate VulkanHeadersConfig.cmake and version file and install them.
To get the version information the header file vulkan_core.h is parsed.
In client code one can use `find_package(VulkanHeaders)` and get the
targets `Vulkan::Headers` and `Vulkan::Registry`.
The following additional files are generated and installed by CMake:
- VulkanHeadersConfig.cmake: searched for by find_package(VulkanHeaders)
- VulkanHeadersConfigVersion.cmake: provides version numbers
- VulkanHeadersTargets.cmake: CMake target definitions used by config file
Adds alias interface libraries Vulkan::Headers and Vulkan::Registry that
export include paths. These are meant to be used by dependent projects
in a nested build configuration to obtain the path to the Vulkan headers
and registry directories.
Change-Id: I0801f4a23ef654064c1b0878543cd48965954756
Use CMAKE_CURRENT_SOURCE_DIR instead of CMAKE_SOURCE_DIR when defining
the path for the source files to be installed.
CMAKE_SOURCE_DIR always points at the directory containing the root
CMakeLists.txt, while CMAKE_CURRENT_SOURCE_DIR points at the directory
containing the current project's CMakeLists.txt. These are normally
identical, except when another CMake project includes this project via
add_subdirectory() --- in that case, CMAKE_CURRENT_SOURCE_DIR is the
right variable to use when composing paths to files within the current
project tree.
Change-Id: I4bdcc3bf538e96c43ae5f4ff6758cf45992442e0
A cleanup of the CMake file in this repo,
for consistency with similar effort in other Vulkan repos.
clarify setting Windows install prefix if needed
project() : NONE = this project has no language toolchain requirement.
update .cmake-format.py 0.4.1
reformat using cmake-format 0.4.1
Change-Id: Ic64b335676eb6b8bd8ffd1b0d8c5468a4239287c
Allows for this repo to be included as a submodule of another
repo that defines its own uninstall target. The uninstall target
is best defined at the top-level repo.