Windows build not working

[MennoVink]

Environment:

• OS: Windows
• SDK or header version if building from repo: vulkan-sdk-1.3.280

Describe the Issue

I cannot build the repo after having a fresh checkout. First i checked opening the folder with CMake GUI. When that didn't work i followed these steps which are giving me the same problems:

-- Detecting CXX compile features - done
-- Could NOT find robin_hood (missing: robin_hood_DIR)
-- Could NOT find mimalloc (missing: mimalloc_DIR)
-- Configuring done
CMake Error at layers/CMakeLists.txt:75 (target_link_libraries):
  Target "VkLayer_utils" links to:

    Vulkan::Headers

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.



CMake Error at layers/CMakeLists.txt:376 (target_link_libraries):
  Target "vvl" links to:

    SPIRV-Headers::SPIRV-Headers

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.



CMake Error at layers/gpu_validation/spirv/CMakeLists.txt:47 (target_link_libraries):
  Target "gpu_av_spirv" links to:

    SPIRV-Headers::SPIRV-Headers

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.



-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

Expected behavior

With cmake gui i expect to be able to select the source directory, target directory as build subfolder and then press Configure->Generate->Open Project and end up in a visual studio instance able to build the project.

Additional context

The steps here do give me a visual studio project. But it wont build in release nor will the test explorer allow me to run any tests.

[spencer-lunarg]

@christophe-lunarg you said you had this exact same issue yesterday on Windows... how did you get around it?

[spencer-lunarg]

pinging @artem-lunarg / @arno-lunarg as well as our new Window Build experts 😄

[artem-lunarg]

The steps here do give me a visual studio project. But it wont build in release nor will the test explorer allow me to run any tests.

This part should be straighforward. Debug word should be replaced with Release. Then the test project should be selected as a startup project:

I personally use the following sequence to build the project the first time, this will also generates a VS solution. There is no option to have debug and release configuration in a single solution, I just create two solutions for release and debug in separate folders.

cmake -S vvl -B vvl\build\Release -DUPDATE_DEPS=ON -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release
cmake --build vvl\build\Release --config Release

[christophe-lunarg]

@christophe-lunarg you said you had this exact same issue yesterday on Windows... how did you get around it?

I cleared everything and generate the solution again...

[MennoVink]

Thank you for the quick answers!

Makes sense that the command line would need to be changed when it explicitly requests debug, but realistically i would like to not use the command line at all. The cmake gui tool gives me all available options i can adjust and the options are hidden when using the command line. The problem is that the cmake gui doesn't provide these hidden arguments so using that it cant work.
When you say it's 'no option to have debug and release in a single solution', i'm asuming you mean for this project? Maybe it would be possible to make it an option? I can swap between debug and release in the top header perfectly fine in other cmake projects.

For running tests, maybe i should've been more clear. I am able to run the project as you describe, but this takes a long time (hence i wanted to try release). What i would like to do however is run a single test by using the Test Explorer. I'm using the Test Adapter for Google Test. For example when running NegativeVertexInput:

The test adapter works, for example running only my own DeviceRequirements tests:

[artem-lunarg]

When you say it's 'no option to have debug and release in a single solution', i'm asuming you mean for this project?

Yes, for this specific project. Even if you can select different configurations in combo box I don't think you can build, for example, Release configuration if project was generated for Debug, and vise versa.

[artem-lunarg]

Test Explorer, cmake GUI app

I think these components are not part of the official build configuration so yes, that might not work.

[spencer-lunarg]

@MennoVink sorry to ask, but is the window build working now as expected or is there still something actionable we need to take to fix the CMake code?

[MennoVink]

@spencer-lunarg My expectations may be different from yours, so it's up to you to decide which issues to fix and which ones to ignore. In my view the proposed solutions are workarounds, not fixes. Here's a summary of the issues touched on in the discussion above:

• Make default cmake configuration result in a buildable solution. ie git clone URL && cmake -B build. This will make the current windows build steps be valid while also enabling cmake gui tool usage
• Alternatively update / remove the steps being listed here. Building windows requires the steps from the Building Overview section.
• Add support for amalgamated builds. For both MSVC and Xcode this will result in the ability to switch configurations right from the IDE.

I've been testing a bit more with the Test Explorer, that works on a different machine of mine, so this is most likely user error.

Add support for amalgamated builds. For both MSVC and Xcode this will result in the ability to switch configurations right from the IDE.

VVL's CMake code fine. The problem is update_deps.py. That script/workflow was originally developed for single configuration generators like Make / Ninja. It doesn't work that well with Xcode, Visual Studio, etc.

This line of code right here is a hack. CMAKE_BUILD_TYPE should NOT be used this way. This script was written a while ago and likely developed on Linux where you could basically get away with this.

Make default cmake configuration result in a buildable solution. ie git clone URL && cmake -B build.

That's fine. Just requires making UPDATE_DEPS=ON by default. That will annoy some package managers though. Since many do NOT want us to use that script. It's fine for development. But in terms of performance/security it's not great.

This line of code right here is a hack. CMAKE_BUILD_TYPE should NOT be used this way. This script was written a while ago and likely developed on Linux where you could basically get away with this.

To be clear that's not the only line of code that needs to be fixed. It's just the main indicator of the problem.

[jpr42]

@spencer-lunarg / @artem-lunarg / @charles-lunarg if you are open to it I'm willing to help add/maintain vcpkg to the following projects:

• KhronosGroup/Vulkan-ValidationLayers
• KhronosGroup/Vulkan-Loader
• KhronosGroup/Vulkan-ExtensionLayer
• KhronosGroup/Vulkan-Utility-Libraries
• KhronosGroup/Vulkan-Tools
• KhronosGroup/Vulkan-Profiles
• any other project that uses update_deps.py

IE replacing update_deps.py with vcpkg (IE a proper package manager).

Not only will this properly handle multi-configuration generators. But will also help a LOT with build times.

Because vcpkg actually has binary caching:
https://learn.microsoft.com/en-us/vcpkg/users/binarycaching

Let me know if you are interested.

[spencer-lunarg]

@jpr42

My boss:

"Sure. We take contributions."

I'm personally all for this as well. I've not been a fan of update_deps.py but its been "good enough" to not anger me enough to go do this