References to undefined CAMetalLayer, etc. symbols

[emidoots]

As of ac4103a733c479b599aae8d42c08cabd7d5cf48a vulkan-zig generates some references to undefined macOS Zig symbols like CAMetalLayer:

https://github.com/hexops/vulkan-zig-generated/blob/836219ff4305889c4634e90c0d2e9038b8d56c37/vk.zig#L2364

We workaround this currently by appending them to the generated file:

https://github.com/hexops/vulkan-zig-generated/blob/836219ff4305889c4634e90c0d2e9038b8d56c37/update.sh#L18-L24

I've had a TODO to clean this up for a while https://github.com/hexops/mach/issues/822 but just remembered it, so figured I'd file an issue here. Hope that's okay!

[Snektron]

Hmm, these were previously supplied by the user. Fyi, there are probably done other types that are broken like this. I wonder why the stuff to define them isn't being generated anymore...

[Snektron]

As far as I can see, these types are still generated. Furthermore, this is actually intentional. The vulkan-zig definition for these types is as follows:

pub const CAMetalLayer = if (@hasDecl(root, "CAMetalLayer")) root.CAMetalLayer else @compileError("Missing type definition of 'CAMetalLayer'");

For some foreign types a default is provided, where reasonable. I do not know what type CAMetalLayer is, nor does the Zig standard library provide it. This is why its supposed to be provided as an external type. I guess this is rather obscure functionality.

This should also be the case in your version. @slimsag is this still an issue on your end? It seems to be generating fine for me, on both the xml in the repository and the latest vk.xml. Does the above mechanism provide enough integration for you? I guess if the Mach application defines the main(), then it will be relatively weird to have the user define it. If you have an idea for how to better provide it, please let me know.

I guess for now, we can use opaque{} as a default for CAMetalLayer, but there are still some other types where that will be relatively hard for.

[emidoots]

Ok, perhaps I don't have the latest vk.xml or something. As long as it works for you, I can figure out whatever is broken on our end.

I guess for now, we can use opaque{} as a default for CAMetalLayer, but there are still some other types where that will be relatively hard for.

Providing these types, as opaque{} or otherwise, would definitely be my preference. If there are other types vulkan-zig cannot define/provide, perhaps generic parameters somewhere could be used?