Sharadh Rajaraman

@asuessenbach I will close this; I have opened #2372 and #2373 instead.

Hi @asuessenbach! I've been meaning to do this for a while, actually. I have a list of things that I found a little less than ideal with the current readme:...

The initial PR (#1582) that first introduced the module called it `module vulkan`. This was then changed in #1651. I'm not entirely sure why and personally I also prefer `module...

> so that the module no longer needs to include the `vulkan_hpp_macro.hpp` header It should; we still have `VULKAN_HPP_STRINGIFY` for the warnings! But this wasn't removed anyway... Also, I'm not...

Side note: I realised `#warning` is [in the C++23 standard](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2437r1.pdf), but MSVC hasn't implemented it yet (sigh).

A cursory glance shows no glaring issues. That singular build failure should probably be resolved by rebasing atop `main`. However I am surprised it did not fail on any other...

> Windows Clang has too old of a CMake version, same for MSVC This is surprising! Visual Studio bundles CMake 4.1. Or we can always install the upstream CMake with...

> I would simply exclude the module-related things from CI. Is that acceptable or should I tear these apart on a deeper level? I think just having the module stuff...

@oddhack this failure will be resolved by [KhronosGroup/Vulkan-Headers/#569](https://github.com/KhronosGroup/Vulkan-Headers/pull/569).

Indeed. I think it's best to keep testing/building within this repository, including the experimental UUID and module setup. All this will naturally be removed once CMake removes that UUID. `Vulkan-Headers`...