[sharadhr]

An experiment to modularise the samples. utils and RAII_utils are provided as named modules, and all the samples consume them as executables in normal translation units.

This is largely AI-generated (not this commit message), and linker errors are still seen in my local experiments. Do not merge yet.

[sharadhr]

I think this is mostly ready, but this branch also includes changes to make Vulkan-Hpp ready for proposed changes in CMake 4.5 that aren't in the public releases yet. These include temporary changes in CI to pull and build with CMake's nightly builds.

Additionally, the MSVC build appears to fail regularly with the following error:

FAILED: [code=2] RAII_Samples/utils/CMakeFiles/RAII_utils_module@synth_0.dir/e9d132dddfaf.bmi 
"C:\Program Files\Microsoft Visual Studio\18\Enterprise\VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64\cl.exe"  /nologo /TP -DVK_NO_PROTOTYPES -DVK_USE_PLATFORM_WIN32_KHR -DVULKAN_HPP_DISPATCH_LOADER_DYNAMIC -ID:\a\Vulkan-Hpp\Vulkan-Hpp\glfw\include -ID:\a\Vulkan-Hpp\Vulkan-Hpp\glm -ID:\a\Vulkan-Hpp\Vulkan-Hpp\glslang\glslang\.. -ID:\a\Vulkan-Hpp\Vulkan-Hpp\build\include -ID:\a\Vulkan-Hpp\Vulkan-Hpp\glslang\SPIRV\.. -ID:\a\Vulkan-Hpp\Vulkan-Hpp -ID:\a\Vulkan-Hpp\Vulkan-Hpp\Vulkan-Headers\include /EHsc /Zi /Ob0 /Od /RTC1 -std:c++latest -MDd -ifcOnly -ifcOutput RAII_Samples\utils\CMakeFiles\RAII_utils_module@synth_0.dir\e9d132dddfaf.bmi /showIncludes @RAII_Samples\utils\CMakeFiles\RAII_utils_module@synth_0.dir\e9d132dddfaf.bmi.modmap /FoRAII_Samples\utils\CMakeFiles\RAII_utils_module@synth_0.dir\e9d132dddfaf.bmi /Fd"" /FS -c D:\a\Vulkan-Hpp\Vulkan-Hpp\RAII_Samples\utils\RAII_utils.cppm
RAII_utils.cppm
D:\a\Vulkan-Hpp\Vulkan-Hpp\RAII_Samples\utils\RAII_utils.cppm: fatal error C1041: cannot open program database 'D:\a\Vulkan-Hpp\Vulkan-Hpp\build\vc140.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS

The invocation does contain /FS, but it still shows up. I think I may set CMAKE_MSVC_DEBUG_INFORMATION_FORMAT to Embedded as a fix. @asuessenbach do you have any possible thoughts on fixing this?

Additionally as a stretch goal I want to provide benchmarks, as I think this build of the samples is a reasonably complex attempt at a (mostly) modularised project. To give some preliminary data, I am seeing something like a 2× speedup over a pure header build, and it is slightly slower than the PCH build, but changing a header (and therefore changing the PCH interface and module interface) is much faster. I suspect there is plenty of low-hanging fruit to resolve to speed up the module build.

[M2-TE]

Do you encounter the MSVC build errors only on CI, or also on local runs?
There was an MSVC issue with FS access during async operations when we generated headers in parallel.
Tried to fix it a bunch of times but never managed, here was the first time I tried: #2084
Figured they may be related.

I suspect there is plenty of low-hanging fruit to resolve to speed up the module build.

Indeed. Something that may be even more important than full compilation benchmarks would be iterative builds. Leave the PCH/module as is and just change code that includes/imports those. PCHs are quite large so perhaps there's a measurable difference there. Binary size may also be of note.

[asuessenbach]

There's one thing that makes me wonder: where does that Vulkan-Hpp\build\vc140.pdb come from?
I think, every sample uses a separate directory to store its pdb file?

[M2-TE]

The utils module is shared between the samples; thats where the concurrent access should be coming from

[sharadhr]

Do you encounter the MSVC build errors only on CI, or also on local runs?

I saw it locally in a previous commit, but it seems to have gone away.

[sharadhr]

Ah. The macOS build fails because that workflow uses CMake 4.1.2, whereas I have modified the CMakeLists to expect 4.5 behaviour (removed CXX_IMPORT_STD etc).