Use vcpkg for dependency management by jpr42 · Pull Request #1964 · KhronosGroup/Vulkan-Loader

jpr42 · 2026-07-10T01:22:36Z

Replace the custom scripts/update_deps.py dependency fetcher with vcpkg in manifest mode for Vulkan-Headers, googletest, and (on Windows) detours.

BUILD.md is updated to document the vcpkg-based setup.

Also fixes scripts/gn/gn.py to use subprocess.run(check=True) instead of subprocess.call, a drive-by fix unrelated to vcpkg: the previous calls silently ignored non-zero exit codes. Caught this during my work on vcpkg to make sure I didn't accidentally break the chromium build.

Replace the custom scripts/update_deps.py dependency fetcher with vcpkg in manifest mode for Vulkan-Headers, googletest, and (on Windows) detours. BUILD.md is updated to document the vcpkg-based setup. Also fixes scripts/gn/gn.py to use subprocess.run(check=True) instead of subprocess.call, a drive-by fix unrelated to vcpkg: the previous calls silently ignored non-zero exit codes. Caught this during my work on vcpkg to make sure I didn't accidentally break the chromium build.

ci-tester-lunarg · 2026-07-10T01:22:38Z

Author jpr42 not on autobuild list. Waiting for curator authorization before starting CI build.

ci-tester-lunarg · 2026-07-10T01:22:38Z

Author jpr42 not on autobuild list. Waiting for curator authorization before starting CI build.

spencer-lunarg · 2026-07-10T01:53:51Z

we are about to release a SDK in 2-ish weeks, I am curious if we want to get these all ready and merge it in after... not sure on the implication it will have (cc @richard-lunarg)

jpr42 · 2026-07-10T02:10:33Z

For the loader the impact should be negligible. The SDK doesn't use update_deps.py IIRC.

charles-lunarg · 2026-07-10T02:28:07Z

Having had a quick look through the changes, the big issue blocking this will be downstream consumers of Vulkan-Loader. Because this yeet's the update_deps.py script, any consumer of Vulkan-Loader that uses -DUPDATE_DEPS=ON today will be broken when they update to this commit. Keeping the update_deps.py path for now is likely necessary during rollout.

charles-lunarg · 2026-07-10T02:30:50Z

For the loader the impact should be negligible. The SDK doesn't use update_deps.py IIRC.

Correct, however it does use a script that knows the dependencies between each repo then propagates each repo's dependencies using <dep>_INSTALL_DIR command line variables. This ensures everything is using the 'correct' version of dependencies.

jpr42 · 2026-07-10T03:06:32Z

Correct, however it does use a script that knows the dependencies between each repo then propagates each repo's dependencies using <dep>_INSTALL_DIR command line variables. This ensures everything is using the 'correct' version of dependencies.

For context those various <dep>_INSTALL_DIR command line variables can all be replaced with CMAKE_PREFIX_PATH. Those custom variables never needed to exist for find_package support.

jpr42 · 2026-07-10T16:34:09Z

+# the builtin-baseline in vcpkg.json.
+#
+# IMHO this is less work moving forward than trying to maintain a separate overlay for vulkan-headers,
+# and it will also make it easier to use the vcpkg port of vulkan-headers in other projects.


@mikes-lunarg since this will (potentially) impact how vulkan-headers is updated in the future.

Here is an example PR up updating upstream vulkan-headers in vcpkg itself:
microsoft/vcpkg#29066

Technically you can just keep on maintaining this custom portfile.

I'm just pointing out that it might be easier to update upstream the builtin-baseline see vcpkg.json.

That way other dependencies like google-test are periodically getting updated as well.

It would also be a nice to have for the entire open source community.

jpr42 · 2026-07-10T16:35:54Z

+# vcpkg manifest-mode install directory (when not nested under a build/ dir)
+/vcpkg_installed/
+


See the codegen CI job for why this was added.

jpr42 · 2026-07-10T16:36:56Z

                -D BUILD_TESTS=ON \
-                -D UPDATE_DEPS=ON \
+                -D VCPKG_MANIFEST_FEATURES=tests \
+                -D "CMAKE_TOOLCHAIN_FILE=${{ env.VCPKG_ROOT }}/scripts/buildsystems/vcpkg.cmake" \


I think we can reduce some code duplication by setting CMAKE_TOOLCHAIN_FILE as an environment variable instead.

jpr42 · 2026-07-10T16:37:58Z

I tested to make sure binary caching was working well on my fork. The benefits should become clear over time. Especially for more complex repos like VVL.

jpr42 · 2026-07-10T16:38:23Z

-else()
-    message(FATAL_ERROR "Could not find googletest directory. See BUILD.md")
-endif()
+find_package(GTest CONFIG REQUIRED)


Much simpler.

jpr42 · 2026-07-10T16:38:57Z

-        target_compile_definitions(detours PUBLIC  "_CRT_SECURE_NO_WARNINGS=1")
-        set_target_properties(detours PROPERTIES COMPILE_FLAGS /EHsc)
-    endif()
+    # vcpkg's detours port ships a prebuilt static lib + headers, not a CMake package config.


New detours code is much simpler.

jpr42 · 2026-07-10T16:39:29Z

+# value supplied this way, and the Makefile's comparisons are all uppercase.
+string(TOUPPER "${VCPKG_TARGET_ARCHITECTURE}" DETOURS_TARGET_PROCESSOR)
+
+vcpkg_build_nmake(


vcpkg has the ability to interact with build systems aside from CMake.

Making it easier than ever to just what you want.

jpr42 · 2026-07-10T16:41:54Z

See official vcpkg documentation:
https://learn.microsoft.com/en-us/vcpkg/get_started/get-started?pivots=shell-powershell#1---set-up-vcpkg

Configuring the VCPKG_ROOT environment variable isn't just a random convention I made up.

jpr42 · 2026-07-10T16:48:31Z

Furthermore, if every package eventually gets updated into vcpkg proper. It would trivialize creating the vulkan-sdk.

You can get a sense for this by looking at the codegen job:

    codegen:
      runs-on: ubuntu-latest
      timeout-minutes: 30
      steps:
        - uses: actions/checkout@v7
        - uses: ./.github/actions/setup-vcpkg
          with:
            job-index: ${{ strategy.job-index }}
            run-vcpkg-install: 'true'
            vcpkg-installed-dir: ${{ github.workspace }}/vcpkg_installed
        - run: scripts/generate_source.py --verify vcpkg_installed/*/share/vulkan/registry

The idea being once everything is updated upstream in vcpkg proper you just run vcpkg to build everything easily. That's looking ahead in the future but I think it's a great idea.

jpr42 · 2026-07-10T17:03:52Z

Also vcpkg will be much friendlier to other contributors compared to update_deps.py which is a highly custom workflow with various gotchas.

jpr42 · 2026-07-10T17:04:59Z

And while I am more than happy to look after things for a while since life is going great right now.

vcpkg is open source with good documentation. So there is plenty of resources on how to use it properly. Instead of hidden wisdom in python scripts that don't make sense anymore.

This was referenced Jul 10, 2026

update_deps: Clone with --filter=tree:0 to decrease download size #1623

Closed

Windows build not working KhronosGroup/Vulkan-ValidationLayers#7891

Open

jpr42 commented Jul 10, 2026

View reviewed changes

jpr42 mentioned this pull request Jul 10, 2026

Use ccache for CI #1965

Open

		# vcpkg manifest-mode install directory (when not nested under a build/ dir)
		/vcpkg_installed/

Uh oh!

Conversation

jpr42 commented Jul 10, 2026

Uh oh!

ci-tester-lunarg commented Jul 10, 2026

Uh oh!

ci-tester-lunarg commented Jul 10, 2026

Uh oh!

spencer-lunarg commented Jul 10, 2026

Uh oh!

jpr42 commented Jul 10, 2026

Uh oh!

charles-lunarg commented Jul 10, 2026

Uh oh!

charles-lunarg commented Jul 10, 2026

Uh oh!

jpr42 commented Jul 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jpr42 commented Jul 10, 2026

Uh oh!

jpr42 commented Jul 10, 2026

Uh oh!

jpr42 commented Jul 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants