"Header only" with portable dynamic linking

[robinei]

It would be nice to be able to just copy the headers and maybe a single C file into my project (the C file defines all stubs, and can load the library and setup function pointers on most platforms). That way I would be able to build an SDL application without depending on preinstalled dev packages, or being required to vendor the whole library which will make my project bloated and much harder to build.

Since SDL takes API/ABI compatibility seriously, this would allow me to have a lightweight self-contained repo that I can just check out and build in 10 years, only requiring a C compiler. Of course I would have to find a new enough SDL shared library with matching major version, but then I should be able to run my program.

Or is something like this already supported?

[madebr]

Your question is very close to the problem we're trying to solve with setup-sdl for providing SDL to users.
I recently tried out llvm-ifs to create a stub library, but found out it lacked support for symbol versioning. Static libraries can be ignored.
On Windows, an import library can currently already be built using a .def file.

[robinei]

Interesting. Yeah .def file works on windows, but it would be nice to have a portable solution. I hope this can be a supported way for projects to consume SDL.

[robinei]

volk does this for Vulkan (shipping as a .h and .c pair), supporting Windows, Linux, macOS, iOS and Android.

[madebr]

Creating such a library would add a level of indirection.
When (if) #6337 gets resolved, equivalent sources for SDL3 can be generated relatively easy.

[robinei]

Indirection is fine, since I will not be calling any SDL functions on hot paths.

[icculus]

To be clear, you're just looking to link against something that looks like SDL but isn't actually SDL, to make the builds simpler and avoid revision control bloat. Not looking for a stub thing that loads a real version of SDL at runtime, right?

[icculus]

Actually, it sounds like you're looking for that second thing. I think you should probably aim for the first thing, but the second thing is probably doable by adapting SDL's dynapi code to require loading an external SDL library (as opposed to optionally doing it), and then letting that handle the indirection, etc. This would work even if you statically link the code in a single .c file.

But I suspect having a single C file that just generates the correct SDL symbols, that you build into a shared library that you link against, and provide a real SDL library at runtime, is a better solution.

[robinei]

Having read about the dynapi support, I see that what I want is to an easily vendorable dynapi-only subset of SDL (so no actual implementations). The purpose is to eliminate build-time dependencies, and make projects as simple as possible to build, but still runnable on any system providing the SDL shared library.
Why should I prefer this being in shared library form, and not just compiled into my application?

[icculus]

Why should I prefer this being in shared library form, and not just compiled into my application?

If you just want to have a simple .c file for your build, and you're going to have to provide a shared library at runtime either way, it seems like less complexity to build that one C file as a shared library and link against it, and not have all the extra dynapi mechanism in there, but either way would work.

I guess this is what the dynapi exist for anyhow, right? Statically linking SDL but still allowing a shared library to override it. You're just asking for the static link part to not contain any of the payload and for the overriding to be mandatory.

This...should be doable. Let me think on it a bit.