Add platform APIs support

[ColonelThirtyTwo]

Add bindings for the Vulkan platform extensions.

[ColonelThirtyTwo]

Since the only thing Vulkan needs from each platform's API is a maximum of two types, I think that using specific bindings is risky and inflexible, as bindings differ in terms of features (low vs high level) and maintenance. I don't want to add a left-pad-esque micro-dependency.

Messing with import paths is also not a good solution, because it creates restrictions on the structure of the bindings, and also does not work with dub packages.

Since the only types that Vulkan requires from platforms are pointers-to-structures and typedef'ed integers, I'm thinking about aliasing the structures to void* pointers and the integer types to their internal types. The void pointers may open up a small bit of risk, as the type checker can no longer check the parameter as thoroughly, but since the platform APIs are not very big, I don't see this becoming a huge issue.

The only other alternative I can think of is templating the types and loaders and passing in the types, but that means that the function pointers can no longer be global.

[ParticlePeter]

Since the only thing Vulkan needs from each platform's API is a maximum of two types, I think that using specific bindings is risky and inflexible, as bindings differ in terms of features (low vs high level) and maintenance. I don't want to add a left-pad-esque micro-dependency.

I do understand your issue with third party bindings, but this is the way the original vulkan.h works. With certain macros you choose which parts should be enabled and which not. Wayland for example is quite new, is it already robust enough? If the wayland sources in C world are broken, they can't be used, and the macro must be turned of. Same thing with d bindings/module.

Messing with import paths is also not a good solution, because it creates restrictions on the structure of the bindings, and also does not work with dub packages.

I didn't mean messing, I meant adding paths/to/bindings as sourcePaths and importPaths as compiler flags. I just wrote an example here

Since the only types that Vulkan requires from platforms are pointers-to-structures and typedef'ed integers, I'm thinking about aliasing the structures to void* pointers and the integer types to their internal types. The void pointers may open up a small bit of risk, as the type checker can no longer check the parameter as thoroughly, but since the platform APIs are not very big, I don't see this becoming a huge issue.

In my opinion you would remove and/or change original functionality which is present in vulkan.h and possible in D as well. I think a binding should be as close as possible to the original.

[ColonelThirtyTwo]

I do understand your issue with third party bindings, but this is the way the original vulkan.h works.

Vulkan uses the official C headers of the platforms' libraries. There's no reason for third parties to write other bindings for the C libraries; there are official ones available. If D had official bindings for the platform APIs, I'd use them, but the only platform D has official, builtin bindings for is Windows (which I may actually use). Since there's nothing official, the bindings must be supplied by dub packages, which are more prone to abandonment or duplication.

I didn't mean messing, I meant adding paths/to/bindings as sourcePaths and importPaths as compiler flags. I just wrote an example here

Link is broken. And that's what I meant by 'messing'. I fail to see how source/importPaths will help; you can't effectively point to a dub package (which bindings are likely to be supplied as) and you would need to alter d-vulkan's dub configuration to alter those settings, which is unacceptable.

[ParticlePeter]

True, but this implies that you will never support anything else but windows. Maybe after some time some of these platforms will be added to phobos, but how long will it take for all of them? As long as vulkan bindings are maintained, community is willing to use special cases and invest in a little additional work vulkan bindings should not forbid that.

you can't effectively point to a dub package (which bindings are likely to be supplied as) and you would need to alter d-vulkan's dub configuration to alter those settings, which is unacceptable.

No you don't. Just change the way how you use d-vulkan in your "cool_vulkan_project" dub. "name" : "cool_vulkan_project", "versions" : [ "VK_USE_PLATFORM_XCB_KHR" ], "sourcePaths" : [ "path/to/dvulkan/source", "path/to/xcb/source" ], "importPaths" : [ "path/to/dvulkan/source", "path/to/xcb/source" ],

instead of (code block does not get formated right here): "name" : "cool_vulkan_project", "versions" : [ "VK_USE_PLATFORM_XCB_KHR" ], "dependencies" : {"erupted" : "~>1.1.0", }

Another possibility was given in the example in issue #4 (the broken link). In that case the second dub version above would still be valid. Just copy/add/symlink xcb/xcb.d module under dvulkan/source and specify VK_USE_PLATFORM_XCB_KHR

All the stuff is explained on the erupted README.md. Did you have a chance to read it?

[ColonelThirtyTwo]

True, but this implies that you will never support anything else but windows.

The entire point of this issue is to discuss how to support platform bindings that aren't in Phobos, without tying dvulkan to a specific one.

"sourcePaths" : [ "path/to/dvulkan/source", "path/to/xcb/source" ],

What is the point of having dvulkan be a dub package if you can't use it as a dub package? Exposing only part of the functionality in the dub package is an unacceptable and unnecessary restriction. Neither is modifying the package downloaded by dub to add more source files to it, as you suggest in issue #4, because it won't persist across machines and will break the instant the developer downloads a new version or clears their dub cashes.

If I cannot download my project (and only my project, not with any other dub packages bundled into the repo) onto a completely new machine and run dub build to build it, then it is an unacceptable solution.

[ColonelThirtyTwo]

To be a bit more comprehensive since I'm not sure how exactly you're suggesting this work:

1. Add dvulkan to my project's source, set sourcePaths: "dvulkan/source": It's not a dub package then.
2. Download dvulkan through dub, set sourcePaths: "C:/.../dvulkan": Unreliable; the package may be in different places across systems or if I do dub add-local
3. Add dvulkan as a dub dependency, set sourcePaths: "my/bindings": Dependencies don't inherit sourcePaths.