This is in respect to announce thread:
https://forum.dlang.org/post/mdpjqdkenrnuxvruwoqs@forum.dlang.org

Please let me know if you had the chance to test the functionality as requested in the announce thread.
All other question are welcome here as well of course.

Cheers, ParticlePeter

Hi, Kalua here :)

First, thanks again for fixing vulkanizeD, now I don't have to use my locally patched version anymore ;)

Giving you some input for how your lib works on my posix sytem (arch
linux):

My simple triangle drawing program works with your lib, I only had to update the function loading names I chose differently.

But I had to modify erupteD's dub.json to depend on xcb (dub package xcb-d), because simply putting the xcb dependency in my project's dub.json was not enough. But this should only be a workaround, because not everyone uses/can use xcb, or they may even want to use different xcb bindings.

What I want to do is to tell dub that erupted should depend on
xcb-d in my project's dub.json, is that possible?

On Monday, 16 May 2016 at 12:10:58 UTC, ParticlePeter wrote:
> This is in respect to announce thread:
> https://forum.dlang.org/post/mdpjqdkenrnuxvruwoqs@forum.dlang.org
>
> Please let me know if you had the chance to test the functionality as requested in the announce thread.
> All other question are welcome here as well of course.
>
> Cheers, ParticlePeter

Cool stuff! I think I'll try this out soon on Posix. My Nvidia driver should in theory support Vulkan already.

On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote:
> Hi, Kalua here :)
>
> First, thanks again for fixing vulkanizeD, now I don't have to use my locally patched version anymore ;)

Welcome :-)

> Giving you some input for how your lib works on my posix sytem (arch
> linux):
>
> My simple triangle drawing program works with your lib, I only had to update the function loading names I chose differently.

That's nice to hear!

> But I had to modify erupteD's dub.json to depend on xcb (dub package xcb-d), because simply putting the xcb dependency in my project's dub.json was not enough. But this should only be a workaround, because not everyone uses/can use xcb, or they may even want to use different xcb bindings.

That's right, but if the platform modules are available as dub packages they should be supported somehow.

> What I want to do is to tell dub that erupted should depend on
> xcb-d in my project's dub.json, is that possible?

I am not very confident with dub, but think that it would not work. Maybe you ask in the dub forum?

But I have one idea which might work:
Create a module xcb.xcb.d yourself and publicly import all required sources from xcb-d into it. In your triangle vulkan project add the path to xcb.xcb.d and xcb-d to "sourcePaths" and "importPaths". Erupted might pick it up.

Another way would be, and I think I'll go for it, that I add dub platform configurations. In your case it would be:
"subConfigurations": { "erupted": "dub_platform_xcb" }
which would add xcb-d as dependency and the relevant xcb-d modules in erupted.types.d

> > What I want to do is to tell dub that erupted should depend on xcb-d in my project's dub.json, is that possible?
> 
> I am not very confident with dub, but think that it would not work. Maybe you ask in the dub forum?
> 
> [...]
>
> Another way would be, and I think I'll go for it, that I add dub
> platform configurations. In your case it would be:
> "subConfigurations": { "erupted": "dub_platform_xcb" }
> which would add xcb-d as dependency and the relevant xcb-d
> modules in erupted.types.d
> 

Sounds reasonable, picking a subconfig is definitely easier to use and implement. I was looking into that too, the only nitpicking I have is that it sounded like you can't select multiple subconfigurations. So for corner cases like having your app support xcb and xlib, a new subconfig has to be added. But I'll have to try that for myself.

On another note, while I like the creative package naming, it may not
be very easy for search engines to pick up or recognize by potential
users as vulkan bindings. The project is still new, but
gooogle and duckduckgo don't find erupteD when searching for "dlang
vulkan", but they do find derelict-vulkan, d-vulkan and vulkanizeD. I
hope I'm just overanalyzing, but I think having vulkan in the name
would be good. But I see that we're getting out of naming options
here...

On Tuesday, 17 May 2016 at 20:34:17 UTC, Manuel König wrote:
>> > What I want to do is to tell dub that erupted should depend on xcb-d in my project's dub.json, is that possible?
>> 
>> I am not very confident with dub, but think that it would not work. Maybe you ask in the dub forum?
>> 
>> [...]
>>
>> Another way would be, and I think I'll go for it, that I add dub
>> platform configurations. In your case it would be:
>> "subConfigurations": { "erupted": "dub_platform_xcb" }
>> which would add xcb-d as dependency and the relevant xcb-d
>> modules in erupted.types.d
>> 
>
> Sounds reasonable, picking a subconfig is definitely easier to use and implement. I was looking into that too, the only nitpicking I have is that it sounded like you can't select multiple subconfigurations. So for corner cases like having your app support xcb and xlib, a new subconfig has to be added. But I'll have to try that for myself.

Actually that's a good point, I had also some trouble with this behavior as well already. Do you have any suggestions to solve that?
One way would be using glfw3 or some other platform abstraction layer and not using platform versions yourself.

> On another note, while I like the creative package naming, it may not
> be very easy for search engines to pick up or recognize by potential
> users as vulkan bindings. The project is still new, but
> gooogle and duckduckgo don't find erupteD when searching for "dlang
> vulkan", but they do find derelict-vulkan, d-vulkan and vulkanizeD. I
> hope I'm just overanalyzing, but I think having vulkan in the name
> would be good. But I see that we're getting out of naming options
> here...

I agree with all your arguments, in particular that last one :-) but I think as long as google and duckduck show that something is happening with vulkan in dland its O.K. Diving deeper and using dub package search for vulkan does list erupted. Additionally I asked vinjn/awesome-vulkan and jcoder58/VulkanResources to list erupted as d binding.

On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote:

> had to update the function loading names I chose differently.

This bugged me a little, v1.1.0 has the EruptedLoader struct removed so that the loading functions are called without EruptedLoader. prefix and can be renamed at import. This is a BERAKING CHANGE.

On, 18 May 2016 04:51:10 +0000,
ParticlePeter <ParticlePeter@gmx.de> wrote:
> >
> > Sounds reasonable, picking a subconfig is definitely easier to use and implement. I was looking into that too, the only nitpicking I have is that it sounded like you can't select multiple subconfigurations. So for corner cases like having your app support xcb and xlib, a new subconfig has to be added. But I'll have to try that for myself.
> 
> Actually that's a good point, I had also some trouble with this
> behavior as well already. Do you have any suggestions to solve
> that?
> One way would be using glfw3 or some other platform abstraction
> layer and not using platform versions yourself.

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.
I think the options are
- add ability to dub to allow multiple subconfigurations
- tinker with dub's pre/postGenerateCommands, pre/postBuildCommands

But I think sticking with the simple one-config-per-backend solution is enough. This is more a problem of finding the right balance of an easy to use build tool, and having full control over the build process, and should rather be discussed in a dub thread.

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).

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?