Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:
> Am Wed, 18 May 2016 18:57:48 +0000
> schrieb ParticlePeter <ParticlePeter at gmx.de>:
>
>> On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
>> > On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König 
>> > wrote:
>> > 
>> >> I think I will use glfw3 later. I don't know if the 
>> >> original problem of using multiple configurations (xcb, 
>> >> xlib, glfw3, ...) is possible with only dub's internal 
>> >> logic. I tried putting this in my "vulkantest" packages' 
>> >> dub.json
>> >>
>> >> "subConfigurations":
>> >> {
>> >> 	"erupted": "with-derelict-loader",
>> >> 	"erupted": "normal"
>> >> }
>> >>
>> >> just for testing, and dub told me
>> >>
>> >> Could not resolve configuration for package vulkantest
>> >>
>> >> So I thinnk multiple subconfigurations are not supported.
>> >
>> > The way to handle this is to make multiple configurations of 
>> > vulkantest, one for each of the configurations of erupted 
>> > you want to support. Then, when you build vulkantest, you 
>> > specify the configuration you want to build on the command 
>> > line (unless you're building the default).
>> 
>> This is a good point, the custom project platform 
>> configuration would then be forwarded to erupted. Only 
>> drawback would be that "with-derelict-loader" config is not 
>> available in combination with a platform config, but in the 
>> later case you would want to grab vkGetInstanceProcAddr anyway 
>> in platform specific means.
>> 
>> Manuel, I could just skim over xcb-d. As far as I can see it 
>> has the module xcb.xcb. Is this module sufficient to be 
>> imported in erupted.types.d? In this case I would not have to 
>> touch the erupt.py generator but instead just fix the 
>> erupted.dub file. As you can test it, how about a pull request?
>> 
>
> @ Peter: Yes, importing xcb.xcb is all you need, no patches 
> necessary. But I could patch erupteD's dub.json for an xcb 
> configuration, and maybe put in the readme how to use a 
> configuration, but probably not until sunday.
>
> @Mike: Having multiple subconfigurations (xcb, xlib, glfw3, 
> ...) to pick for the user is the solution Peter was going for, 
> as I understood him. The problem is when a user wants to 
> support both xcb and xlib, or any mix of them. But this is 
> probably just a pathetic use case not relevant in practice, I 
> just stumbled over the question if that is possible when I 
> wanted to add proper xcb, xlib, etc. support to erupteD.

As far as I understand Mike it is still possible. Suppose you 
build an engine based on (d-)vulkan/erupted, lets call it 
Turtle-Engine, you would also specify sub-configurations for xcb, 
xlib, win, ... and you could support any of (d-)vulkans/erupted 
sub-configs in your corresponding configs. When some dude (no 
sexual prejudice meant) wants to write a Turtle-App, which is 
based on your Turtle-Engine he decides how many of your configs 
representing platforms he would like to support. Now you see, as 
the language architect pointed out, its turtles all the way down.