Uh, oh - build failure on windows.

  Performing install step for 'vulkan-shaders-gen'
  -- Install configuration: "Release"
  CMake Error at cmake_install.cmake:39 (file):
    file INSTALL cannot find
    "D:/a/llama.cpp/llama.cpp/build/ggml/src/ggml-vulkan/vulkan-shaders-gen-prefix/src/vulkan-shaders-gen-build/Release/vulkan-shaders-gen.exe":
    No error.

Seems like the new error on windows is exactly the error that I am trying to address on linux.

It seems to me we need to keep the runtime output directory setting then in some cases but not others—or perhaps use some sort of generator expression. There can be issues with multi-configuration generators that we need to ensure work properly.

For example, the reason we set RUNTIME_OUTPUT_DIRECTORY is so the binaries get installed in the same location as the "parent" project.

I'd like to know though what is the difference between the nix builds and the regular Linux builds, and should we bring Nix in line with the Ubuntu builds?

From my observations, the Nix-sandboxed build failure looks like compiler putting the compiled program where it needs to be; but later, when installing from this location to the same location, CMake starts by deleting the target file (equal to the source file) and cannot copy the now-freshly-deleted source file afterwards.

Err hold on I'm going to take a closer look at what the Windows builds are doing. I am starting to see where there might be some problems with those directories.

Okay sorry for the confusion. I think this is a simple issue where the Windows builds are creating a Release build for the Vulkan-shaders-gen and the debug build is expecting it to be in the debug location.

So your proposed change here should be good but it's only part of the picture. 😊

Perhaps:

set(VULKAN_SHADER_GEN_CMAKE_BUILD_ARGS "")
    if (CMAKE_BUILD_TYPE AND CMAKE_BUILD_TYPE MATCHES "Debug|Release|MinSizeRel|RelWithDebInfo")
        list(APPEND VULKAN_SHADER_GEN_CMAKE_BUILD_ARGS --config=${CMAKE_BUILD_TYPE})
    endif()

Is setting the build type but the install command is not using the --config=${CMAKE_BUILD_TYPE}. For multi-configuration generators it also needs to be specified at install time.

So we probably want to add a separate variable like VULKAN_SHADER_GEN_CMAKE_INSTALL_ARGS in similar fashion to the above.

I can confirm that 7c6f434c@0c65422 works on Nixpkgs side, but I don't really use Windows. @AsbjornOlling will you update the PR? Or should I open another one myself to see if CI passes?

@7c6f434c I will update the PR and test if it compiles on windows

EDIT: it doesn't. Fails to compile for windows on both this repo's CI, and my downstream project's CI.

...actually, looks the CI job from this repo for windows/vulkan never ran. Seems like it might have been cancelled because of a failling unit test on another windows target?

@AsbjornOlling The fix has been merged into master—whenever you're ready, merging master into this branch should properly run the changes here. Thanks.

Seems like it's showing the same issue on windows as before.
#14047 (comment)

 Performing install step for 'vulkan-shaders-gen'
  -- Install configuration: "Release"
  CMake Error at cmake_install.cmake:39 (file):
    file INSTALL cannot find
    "C:/a/llama.cpp/llama.cpp/build/ggml/src/ggml-vulkan/vulkan-shaders-gen-prefix/src/vulkan-shaders-gen-build/Release/vulkan-shaders-gen.exe":
    No error.

I wonder how the windows build is different from linux and macos. Could it be something to do with file extensions?
EDIT: nah file extensions seem to be handled by ${_ggml_vk_host_suffix}

@AsbjornOlling I just realized the issue might be with the CMake command-line on the GitHub workflow. The install is specifying a Release build explicitly, but the generation step doesn't specify at all.

For this, I think we need to add -DCMAKE_BUILD_TYPE=Release to the command-line. Otherwise it seems to be defaulting to debug on the generate step (which is where the external project set up).

Okay, sorry for the whirlwind here. In order to properly get this working, I want to restate the issue:

1. When a multi-configuration generator is used, any of the supported configurations may be built (Debug, Release, etc.)—so at generation-time, it cannot assume one. At the moment, this is why the vulkan-shaders/CMakeLists.txt copies all configurations into the same CMAKE_RUNTIME_OUTPUT_DIRECTORY, so no matter which configuration is chosen, the vulkan-shaders-gen.exe will be available.
2. When a single-configuration generator is used, the generate step (using -DCMAKE_BUILD_TYPE=Release) must match the build step (--config Release), which must also match the install step (if it is run).

We are seeing a couple problems with this: (a) the CI job is not specifying the proper generate flags; (b) in order to apply the Nix package fix (removing -DCMAKE_RUNTIME_OUTPUT_DIRECTORY) we need a way to handle case 1 above—and this seems to be simply forwarding the configurations along for gen., build, and install.

ExternalProject_Add(
    vulkan-shaders-gen
    SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/vulkan-shaders
    CMAKE_ARGS 
        ${VULKAN_SHADER_GEN_CMAKE_ARGS}
        -DCMAKE_BUILD_TYPE=$<CONFIG>  # Pass current config
    BUILD_COMMAND 
        ${CMAKE_COMMAND} --build . --config $<CONFIG> ${VULKAN_SHADER_GEN_CMAKE_BUILD_ARGS}
    INSTALL_COMMAND 
        ${CMAKE_COMMAND} --install . --config $<CONFIG>
    INSTALL_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>
)

And we can probably just remove this code because it is encoded in $<CONFIG> now:

    set(VULKAN_SHADER_GEN_CMAKE_BUILD_ARGS "")
    set(VULKAN_SHADER_GEN_CMAKE_INSTALL_ARGS "")
    if (CMAKE_BUILD_TYPE AND CMAKE_BUILD_TYPE MATCHES "Debug|Release|MinSizeRel|RelWithDebInfo")
        list(APPEND VULKAN_SHADER_GEN_CMAKE_BUILD_ARGS --config=${CMAKE_BUILD_TYPE})
        list(APPEND VULKAN_SHADER_GEN_CMAKE_INSTALL_ARGS --config=${CMAKE_BUILD_TYPE})
    endif()

@AsbjornOlling Because this issue seems to extend far beyond the original fix for Nix, I took the liberty to make the batch of Windows changes. Please see #14179 .

To be clear: the main motivation for this PR wasn't to fix nix builds, but to fix vulkan builds of the utilityai/llama-cpp-rs rust bindings. The issue is just most easily reproducible with nix.

Ah—sorry for the confusion. I will update the note on the PR. If you are able to test that one and it fixes the bindings, that would be great! It now passes all the CI checks, but as these things go perhaps the rust bindings do not compile. 😅

Thank you!

Closing as fixed in #14179