Accommodate upstream Windows vulkan_sdk.exe structure changes #21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses an issue with the Vulkan SDK installation on Windows, where recent changes to the installer's structure broke the existing
7z
extraction method and causedFindVulkan
to fail in CMake.Problem
Sometime in the recent past the internal layout of the official Vulkan SDK installers for Windows was modified. As a result, simply extracting the archive with
7z
no longer provides the necessary SDK headers (Include/
directory), making the SDK unusable for compilation.Solution
This PR implements a more robust, "fall-forward" installation strategy for Windows:
vulkan_sdk.exe
archive to see if theInclude/
directory is present at the top level.7z
extraction method.The command used for the new unattended installation is:
./vulkan_sdk.exe --root "$VULKAN_SDK" --accept-licenses --default-answer --confirm-command install
Commentary
While invoking the installer directly is a pragmatic solution, the original preference for
7z
was intentional. Surgically extracting contents is a security-conscious approach that minimizes the potential for side-effects (e.g., avoids creating system menu shortcuts, modifying the registry, or attempting to install other dependencies). It also aligns with the core principle of this action: providing a self-contained SDK environment without system-wide modifications.The need for this change highlights a recurring challenge for open-source maintainers who depend on pre-built artifacts. Seemingly arbitrary changes to tooling and packaging can have a cascading effect, creating downstream work for the volunteer community. A more stable and predictable release process from SDK providers would be beneficial for the entire ecosystem..
See also:
CC: