BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers

I've recently implemented some improvements centered on bindbc-sdl.

== New Loader Function

I've added a function to bindbc-loader (on Windows only) to allow adding a single path to the default DLL search path. This is to solve the problem that some of the SDL satellite libraries would fail to load when placed in a directory outside of the search path, such as a ./libs subdirectory.

The problem is that SDL loads its dependencies dynamically. So when a bindbc user would load a lib with a custom path, e.g., `loadSDLImage("libs\\SDL2_image.dll")`, the system loader would find that DLL just fine, but then when it in turn attempted to load a dependency like libpng, the system loader would search the DLL search path and *not* the libs subdirectory, thereby causing a failure.

Now you can do this:

```
version(Windows) setCustomLoaderSearchPath("libs");

if(loadSDL() < sdlSupport) { /* handle error */ }
if(loadSDL_Image() < sdlImageSupport) { /* handle error */ }

// Give SDL_image a chance to load libpng and libjpeg (it loads them lazily
// when the corresponding flags are passed to IMG_Init.
auto flags = IMG_INIT_PNG | IMG_INIT_JPEG;
if(IMG_Init(flags) != flags) { /* handle error */ }

// Now reset the default loader search path
version(Windows) setCustomLoaderSearchPath(null);
```

It's up to the caller to ensure the path is valid. For example, if the executable is run from a different directory, then "libs" will not be relative to the current working directory. `SDL_GetBasePath` can help there:

https://wiki.libsdl.org/SDL_GetBasePath?highlight=%28%5CbCategoryFilesystem%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29

I'm unaware of any issues with other libraries BindBC binds to, but if they do arise, this will solve those, too.

== SDL_net

I didn't initially port SDL_net over because I didn't think anyone was using it. I was waiting for someone to request it. Someone did. It's a small API, so it took a matter of minutes to complete.

== Streamlined SDL_* version identifiers

Previously, the SDL satellite library bindings could be enabled with e.g., `BindSDL_Image`, `BindSDL_TTF`, etc. That would enable the lowest supported version of the library. To enable a more recent version, an additional identifier was required (`SDL_Image_205`, `SDL_TTF_2014`). That's just dumb. Now, only one identifier is required, e.g., `SDL_Image_205` will do the trick by itself now. `SDL_Image` is equivalent to the `SDL_Image_200`. The old approach is still supported, though, so current build configs should continue to work without change.

See the loader documentation for details on the new function:

https://github.com/BindBC/bindbc-loader

There's also a bit about it in the bindbc-sdl documentation, along with the details about the approach to version identifiers.

https://github.com/BindBC/bindbc-sdl/blob/master/README.md

I've got some bigger packages to port over from Derelict yet (the OpenCL binding, for example). I've also had a request to include support for SDL's thread/mutex API so folks using DasBetterC can have access to it. That's all in the pipeline. Going forward, I plan to devote a handful of hours one day a week to bindbc until I've implemented everything on my task list, so it will get done sooner rather than later.

On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote: > It's up to the caller to ensure the path is valid. For example, if the executable is run from a different directory, then "libs" will not be relative to the current working directory. `SDL_GetBasePath` can help there: > > https://wiki.libsdl.org/SDL_GetBasePath?highlight=%28%5CbCategoryFilesystem%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29 > Well, duh. I put the cart before the horse on that one. SDL2.dll is going to be in the same subdirectory since all the others depend on it and will fail to load if it isn't there (they don't load it dynamically, of course). Working with args[0] or, since this is a Windows-only thing, calling the Win32 API directly (GetModuleFileName, IIRC) will get you there.

On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote: > I've recently implemented some improvements centered on bindbc-sdl. As a user of BindBC (and former Derelict), I really enjoy using those binding libraries. It's some great work, thanks.

On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote: > I've recently implemented some improvements centered on bindbc-sdl. > > [...] A little bit off topic. I wondered whether it is possible to combine dpp and bindbc. Maybe a separate Tool which creates a bindbc packages based on dpp output or even integrates into dpp? Did you already considered s.th. like that? Kind regards Andre

On Saturday, 16 May 2020 at 09:00:25 UTC, Andre Pany wrote: > A little bit off topic. I wondered whether it is possible to combine dpp and bindbc. Maybe a separate Tool which creates a bindbc packages based on dpp output or even integrates into dpp? > > Did you already considered s.th. like that? > Hasn't even crossed my mind. My first thought is that I don't see it as a good fit. Although all of my bindings follow a similar pattern, there are details specific to some of the libraries that led me to break the pattern. This arises mostly in the way different libraries handle their release versioning. Given dpp's use case, I don't see it as a generator of bindings that cover multiple library versions.

On 22/05/2020 12:21 PM, Daniel C wrote: > Can this library be used in a 64-bit build? I only see the one lib, and was curious if the function definitions make any assumptions about argument size or stack configuration etc. There are no binary files provided in the bindbc-sdl repository. https://github.com/BindBC/bindbc-sdl It is a binding, it should match 1:1 definition wise to the C definition.

> There are no binary files provided in the bindbc-sdl repository. > > https://github.com/BindBC/bindbc-sdl > > It is a binding, it should match 1:1 definition wise to the C definition. There is a library file included in the dub repository download: https://code.dlang.org/packages/bindbc-sdl Also, when setting it to static compile, it complains during linking there are missing functions, even though I've already added the appropriate SDL library files. Oddly, when I use dub to compile the library file for bindbc-sdl, when I include that library file during linking it causes an error that it's not a valid library file... even though it was created with dub + dmd? Some odd things going on. I'm on Windows 7 x64 btw Thanks

On Friday, 22 May 2020 at 22:20:55 UTC, Daniel C wrote: > > There is a library file included in the dub repository download: https://code.dlang.org/packages/bindbc-sdl What download are you referring to? I don't have any library files in the git repository, and I don't know of any downloads from the duo repository. > Also, when setting it to static compile, it complains during linking there are missing functions, even though I've already added the appropriate SDL library files. What are the missing symbols? > > Oddly, when I use dub to compile the library file for bindbc-sdl, when I include that library file during linking it causes an error that it's not a valid library file... even though it was created with dub + dmd? Some odd things going on. I'm on Windows 7 x64 btw Are you building it separately from your app? Or is it a dependency in your app's dub configuration? Please provide the commands you are using and the errors you are seeing. Then I can have an idea of what's going on.

Forums