Vulkan-Hpp planning to split vulkan.hpp into multiple files

[oddhack]

Per KhronosGroup/Vulkan-Hpp#979, Vulkan-Hpp is proposing to split vulkan.hpp into several different files. This change will be reflected in Vulkan-Headers per KhronosGroup/Vulkan-Headers#204. We are unsure of the downstream impact to projects like the loader and SDK, so this is a tracker for getting feedback.

Assigning to @KarenGhavam-lunarG as this is probably largely in LunarG's ballpark in terms of constructing SDKs and whatever internal use of vulkan.hpp your projects have.

[charles-lunarg]

As far I am aware, the only major usage of vulkan.hpp is vkcubepp.

The SDK itself has a few small things which make use of it, such as project templates for Visual Studio, documentation of the templates/components of the SDK, or sdk build tests that make sure vulkan.hpp exists and works.

The loader has the text vulkan.hpp in one place and one place only, loader/CMakeLists.txt. It is in a list of the Vulkan-Headers include files for use in the mac build. Would be trivial to add more header files.

[KarenGhavam-lunarG]

We need to do a more indepth analysis and will answer once we have done so.

I am more interested in what are the impacts to the application developers already using vulkan-hpp. Does this change require developers to modify their applications?

[lunarpapillo]

Does this change require developers to modify their applications?

I believe any developer that uses an enum, function, handle, or struct from vulkan.hpp will fail to compile with the proposed change, until they include the additional headers.

A backwards-compatible solution is possible (i.e. turn vulkan.hpp into a header that includes all the generated headers, and then split what used to be vulkan.hpp into vulkan_core.hpp, vulkan_enums.hpp, vulkan_funcs.hpp, vulkan_handles.hpp, and vulkan_structs.hpp). This would allow existing applications to be unaffected, while letting new and modified applications select only the header subsets they want. I'm not sure why this solution or something similar isn't being considered.

[KarenGhavam-lunarG]

We are unsure of the downstream impact to projects like the loader and SDK, so this is a tracker for getting feedback.

The Vulkan loader is not impacted by this change. The Vulkan SDK will automatically pick up any new HPP header files that are added to the Vulkan-Headers repository.

I believe any developer that uses an enum, function, handle, or struct from vulkan.hpp will fail to compile with the proposed change, until they include the additional headers.

Upon further review of the change, it was confirmed that there is not any backwards compatibility caused by the HPP change nor will applications need to change.