KhronosGroup
cube: Make Volk requirement explicit
See also:
Cannot build DEMOS.sln
https://gitlab.khronos.org/vulkan/Vulkan-SDK-Packaging/-/issues/1417
Volk requires that VK_NO_PROTOTYPES be defined before vulkan.h or vulkan.hpp is included. Currently, the various flavors of vkcube hide this definition in the cube/CMakeLists.txt file, which can confuse users who may copy the source for their own use, and may require investigation to figure out why it doesn't "just work".
This change makes the #define explicit in the cube.c and cube.cpp source files, which should both be clearer and be more similar to how most applications use Volk.
Seems like the define needs to be added to these files as well: https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/macOS/cube/DemoViewController.m https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/macOS/cubepp/DemoViewController.mm
Seems like the define needs to be added to these files as well: https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/macOS/cube/DemoViewController.m https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/macOS/cubepp/DemoViewController.mm
:rofl: you figured this out before I did! Blast it, I didn't see your response here while I was working it out in the Vulkan-SDK-Packaging issue - would have saved me some time and kept me from pulling as much of my already sparse hair out...
@charles-lunarg @mikes-lunarg I noted this in the issue, and am reiterating it here...
Is it better to remove the
#include <MoltenVK/mvk_vulkan.h>line fromDemoViewController, or better to keep it and just add a#define VK_NO_PROTOTYPESabove it in that same file? (By "better", I think I mean: which demonstrates to the user the more correct usage?)
The point of doing this as a Vulkan-Tools change instead of an SDK change is to make the use of Volk more "proper". But I'm not sure which of the above is more "proper"...
From @charles-lunarg :
Removing the mvk_vulkan.h is correct- that was an OLD way of using moltenvk anyhow (aka a "private" header from moltenvk that defined vulkan API things outside of the actual vulkan API headers)
So I'm sticking with the current implementation. I'll rebase to make sure nothing has staled.
For anyone reading this comment thread, I would like to clarify that mvk_vulkan.h isn't "outdated" but rather contains stuff not in standard vulkan, and therefore isn't cross platform. vkcube & vkcubepp do not use anything in the header, so its safe to remove.