SDL_GetWindowWMInfo is inaccessible (again?)

[acmcarther]

I'm attempting to hook together vk-sys and a window produced by this library from scratch. For lack of the newest SDL2 vulkan features, which has these methods:

SDL_Vulkan_LoadLibrary()
SDL_Vulkan_GetVkGetInstanceProcAddr()
SDL_Vulkan_GetInstanceExtensions()
SDL_Vulkan_CreateSurface()
SDL_Vulkan_GetDrawableSize()
SDL_Vulkan_UnloadLibrary()

I went the route of trying to get the raw platform-specific window from the SDL_Window object. To do this, you need the method SDL_GetWindowWMInfo, but it appears to have briefly popped into existence in rust-sdl2 (7623bd5) before popping back out of existence when bindgen usage started.

Is there a mechanism I'm missing to access SDL_GetWindowWMInfo? I sort-of suspect that these might just be getting missed during the bindgen pass since they live in separate header files, but I'm not well informed about bindgen.

[Cobrand]

Woops, that was not expected. I don't understand how every C function was generated by bindgen, but not this one... It would help to know when SDL_GetWindowWMInfo was added so that we can pinpoint why GetWindowWM was not in the included headers in sdl2-sys.

[acmcarther]

In that case, I'll take a look and see if I can understand how bindgen is locating these.

From this git blame of a mirror of the repository, it seems to be a pretty old function from the SDL1 days: https://github.com/spurious/SDL-mirror/blame/master/include/SDL_syswm.h#L312.

[Cobrand]

It's documented somewhere how bindgen finds the headers, I think in the Readme. Try to use the pkg-config feature on Linux/Mac or use the env variable to set your custom sdl2 headers, that will give you a clue with bindgen. ⁣Sent from TypeApp ​

…

On Jan 19, 2018, 08:49, at 08:49, Alex McArther ***@***.***> wrote: In that case, I'll take a look and see if I can understand how bindgen is locating these. From this git blame of a mirror of the repository, it seems to be a pretty old function from the SDL1 days: https://github.com/spurious/SDL-mirror/blame/master/include/SDL_syswm.h#L312. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #744 (comment)

[acmcarther]

I believe this was an issue on my end. I'm now performing the bindgen manually on my SDL includes, using nearly the same wrapper.h as in the repo:

#include "SDL.h"
#include "SDL_syswm.h"
// Might as well bring in vulkan while I'm at it.
#include "SDL_vulkan.h"

I'm not using cargo, so the process is roughly:

1) Pass the bespoke wrapper.h to bindgen 
(with the SDL2 includes near enough by to be #included)
2) Generate a surrogate sdl2-sys crate using that new .rs file
3) Replace all sdl2-sys deps globally with the surrogate crate

As a side note, this required an additional flag to bindgen: --rustified-enum ".*", as there was a breaking change in bindgen-0.31.0 that changes enums from being "rust like", into being simple constants. See the patch notes for full details. Upgrading this crate without using the back-compat flag is something I'm not well equipped to understand the implications of, but it probably needs to get done at some point.

[Cobrand]

Since those two header files are going to be needed by other people as well, we could maybe add the option to add them a features in sdl2-sys. e.g. feature "include-syswm" adds the SDL_syswm.h header in bindgen, and another feature for vulkan as well...

The question is: are those functions included in SDL but "hidden" from the headers, or do you have to build a custom fork of SDL2, or even link another dynamic library, ...?

[acmcarther]

I don't believe these functions are hidden -- I think I was performing bindgen incorrectly when trying to use the default sdl2-sys. The existing file includes "<SDL_syswm>", so it should be good to go. That said, it would probably be a good idea to regenerate the pre-generated bindings, as they appear at first glance to have been generated from a wrapper.h that did not include <SDL_syswm>. I can try to do this and submit a PR here but my environment is super weird so I'd be relying on the CI to catch anything anomalous.

In any case, it so happens that I am building a custom fork of SDL2, but I don't believe it was related to the issue at hand.