(Meta Issue) Improve build times

[SaschaWillems]

We did several big improvements to the build times for our samples, but build still take too long. This is an issue for maintainers, and esp. if you work on the framework. Even on a decent CPU a build takes up to 5 Minutes, which is esp. annoying when working on the framework.

For comparison: On m setup (Windows, AMD Ryzen 8 Core CPU) building this repo takes ~5 Minutes, while doing a full rebuilt of my own repo (~70 samples) only takes about 50s.

[DanielAtCosmicDNA]

I believe it might be worth to switch from git submodules to vcpkg packages to improve build times. I was able o achieve faster build times this way, take for example the fork I created to support this issue.

[SaschaWillems]

Probably not gonna happen. We discussed vcpkg in the past, but the samples support (and are used) on platforms where vcpkg is not available.

[DanielAtCosmicDNA]

Probably not gonna happen. We discussed vcpkg in the past, but the samples support (and are used) on platforms where vcpkg is not available.

Can you better elaborate on which platforms vcpkg is not available?

Additionally, the use of Ninja with parallel build is helpful to reduce build times especially for computers with many CPU cores. If you take a look at the fork, Ninja is also setup to build with multiple cores there.

[SaschaWillems]

See https://github.com/KhronosGroup/Vulkan-Samples/pull/909

[DanielAtCosmicDNA]

Probably not gonna happen. We discussed vcpkg in the past, but the samples support (and are used) on platforms where vcpkg is not available.

Can you better elaborate on which platforms vcpkg is not available?

Additionally, the use of Ninja with parallel build is helpful to reduce build times especially for computers with many CPU cores. If you take a look at the fork, Ninja is also setup to build with multiple cores there.

Thank you for clarifying the team’s stance on this! I completely understand the hesitation to introduce new dependencies, especially if platform support is a concern.

For context, vcpkg does officially support Windows, Linux, macOS (including Apple Silicon), and even cross-compilation for embedded/niche targets (e.g., via community triplets). That said, I recognize there may be specific platforms in the Vulkan Samples’ scope (e.g., Android, consoles, or proprietary systems) where vcpkg isn’t viable or adds unnecessary overhead.

If there are platforms the samples target that lack vcpkg support, that’s a totally valid reason to avoid it. However, for desktop platforms (where most contributors/testers likely operate), vcpkg could simplify dependency management without locking the repo into a single package manager. For example:

• Using vcpkg as an optional tool for contributors who prefer it (e.g., via vcpkg.json manifest and conditional CMake logic).
• Keeping existing build systems (e.g., embedded submodules, system packages) as the default for broader compatibility.

That said, I respect the maintainers’ judgment here! If there are specific technical or philosophical blockers (e.g., minimalism, platform toolchain conflicts), I’d love to hear more details. I’m happy to help investigate workarounds if useful, but no pressure—just wanted to share the perspective that vcpkg can actually coexist with multi-platform workflows and help shaving build times.

[SaschaWillems]

Well, submodules are not an issue in regards to build times. So I'm not sure what moving to vcpkg would add other than maintainers (like me) learning to work with a new build tool.

But we discussed that in detail in #909, and I'd like to keep that discussion out of this issue, which aims at code based build time improvements like code simplification and using C++ modules.

[DanielAtCosmicDNA]

With all things considered, I can think of a strategy to balance mantainability concerns with potential solid build times reduction.

---

🚀 vcpkg + Ninja

Goal: Prove build-time gains with minimal risk.

1. Implement Ninja (Immediate 20% Speed Boost)

• CMake: Create CMakePresets.json to use Ninja:

  {
    "configurePresets": [
      {
        "name": "ninja-vcpkg",
        "generator": "Ninja",
        "cacheVariables": {
          "CMAKE_TOOLCHAIN_FILE": "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake"
        }
      }
    ],
    "buildPresets": [
      {
        "name": "build-ninja",
        "configurePreset": "ninja-vcpkg",
        "jobs": 0  // Auto-scales to CPU cores
      }
    ]
  }
  

2. Migrate GLFW to vcpkg

• Change: Replace the GLFW submodule with vcpkg:

  // vcpkg.json
  {
    "dependencies": ["glfw3"]
  }
  

• CMake: Replace add_subdirectory(external/glfw) with:

  find_package(glfw3 CONFIG REQUIRED)
  

3. CI Optimization (GitHub Actions Example)

- name: Cache vcpkg
  uses: actions/cache@v3
  with:
    path: ${{ env.VCPKG_ROOT }}/installed
    key: vcpkg-${{ runner.os }}-glfw3

- name: Build
  run: cmake --preset=ninja-vcpkg && cmake --build --preset=build-ninja

---

📊 Key Technologies Compared

Technology	Submodules	vcpkg + Ninja
GLFW Build	~30s (source)	0s (prebuilt)
Parallelism	Manual (/MP)	Automatic (Ninja)
CI Rebuilds	Full rebuild	Cache-hit: ~5s
Setup Complexity	Low	Moderate (one-time)

--

** Possible Maintainers Strategy **

• GLFW seems to be the heaviest non-header dependency here, vcpkg to the rescue.
• Ninja accelerates all builds, even submodule-based ones.
• Low Risk: Other deps (glm, stb) can remain submodules for the time being and possibly be part of future incremental migrations.

[SaschaWillems]

We did improve build times over time, I'm happy with them as of today. Once we move the Vulkan-hpp samples to modules, build times will improve further.