Closed kcking closed 2 years ago
Thanks! Want to run the generator for the update too?
Ah yes that was too easy... 😅 forgot about the generator.
@Ralith I added two commits to fix the build errors, except that VkImageCreateFlags
and VkImageUsageFlags
are undefined. It appears OpenXR-SDK assumes these are imported from vulkan.h. ash
is currently a dependency of openxr
but not sys
. Should I add ash
as a dep of sys
and either 1) typedef or 2) substitute those types for the associated ash::vk::
types?
No, ash
should not be a dependency of either crate. The new Vulkan types should be handled consistently with the existing ones, by transcribing the bare minimum representation into sys/src/platform.rs
. This ensures we don't break every time ash
updates.
Generating atom definitions automatically is nice, but should probably be pursued in a separate PR. Note that we currently have handwritten definitions for most of them in sys/src/lib.rs
.
Great, thanks for the comments! Latest version now pushed. I have it down to some new FB spatial anchor/Space struct issues.
UuidEXT
struct that holds a 32-byte array. should we create a wrapper for this, or just export it as-is? If users wanted to manipulate the UUIDs instead of just using them as opaque handles, passing them to the uuid
crate seems easy enough. UuidEXT
currently fails the && x.static_array_len.is_none()
check of is_simple_struct
.SpaceQueryCompleteFB
turn XrResult
into Result
which is then conflicting with std::Result
. do we have an existing solution for this? should we be mapping XrResult
to Result<()>
?Thanks for your help!
Applied work-arounds for both of the above issues, let me what you think :)
Published in v0.17.1.
fixes macOS build with https://github.com/KhronosGroup/OpenXR-SDK-Source/pull/323