Update/merge Vulkan-Video C++ named module with main C++ named module

[sharadhr]

The Vulkan-Video C++ named module was created a while ago and hasn't really been maintained since: https://github.com/KhronosGroup/Vulkan-Hpp/blob/07a9e8911c91bf923c5fd790bd68db0af4efc982/vulkan/vulkan_video.cppm#L20

We should spend some time updating this to coincide with updates for the main named module.

Some questions:

1. Do we keep the module separate?
2. Do we merge it into module vulkan_hpp, with no separation whatsoever?
3. How about a module partition, e.g. module vulkan_hpp:video?

CC: @asuessenbach @M2-TE

[M2-TE]

1. I think we should merge them. It's not a very large module anyways.
2. The separation seems to be the additional video namespace as per VULKAN_HPP_NAMESPACE::VULKAN_HPP_VIDEO_NAMESPACE, so we can nest the export within a video namespace.
3. I'm not too sold on partitions when we are not splitting implementations across different files. Would it really have a benefit that justifies the, albeit very small, additional "complexity"?

[sharadhr]

Getting (2) to work seems like VulkanHppGenerator will need to use #include "VideoHppGenerator.hpp". If that won't be an issue then I can work on a pull request.

[sharadhr]

Okay, I've actually looked at the generators in greater detail, and there's quite a significant degree of separation between VulkanHppGenerator and VideoHppGenerator. Probably wouldn't be a great idea to tie them together.

My thought is to combine (2) and (3). In vulkan.cppm, we can write:

export import :video;

And then in vulkan_video.cppm, we can have:

module;

// same preamble as `vulkan.cppm` including `#define VULKAN_HPP_CXX_MODULE`

export module vulkan_hpp:video;
export namespace VULKAN_HPP_NAMESPACE::VULKAN_HPP_VIDEO_NAMESPACE {
using ...
}

[asuessenbach]

My thought is to combine (2) and (3).

I thinks, that's a viable approach. Would you create a PR resolving this?

[M2-TE]

Merging them as shown would add a hard requirement to compile both of them. Quite a few people still manually create their own CMake targets to compile the vulkan module, so this would complicate things a little I believe?

That is, I would love it if there was a way to make the export optional somehow. Is it legal to wrap an export in a macro?

[sharadhr]

I want to make the module less configurable. An exemplar demonstrating how the CMake target can be produced is also committed—simply add both files to the FILE_SET list under target_sources.

The module mindset ought to be completely different to headers. Header files are separated out primarily to address compile time concerns (and this is especially true for Vulkan-Hpp, which has ~250K lines of code). Modules have no such problem—the compile time is paid once up front, and subsequent compiles are much much faster.

With import vulkan, consumers will now have access to the entirety of Vulkan-Hpp, including the video stuff.