My problem is that my SDL implementation is a small part of a larger project that is an extension of an even larger project that I do not own. Given the distribution model involved, I have very low confidence that I will be able package a text file with my build targets and trust that it will land safely in an appropriate path on the end-users machine where my code can find it.
I want to leverage GameControllerDB, but I do not want to be dependent on an external file that has to travel around with me. My first impulse was to create a std::string variable in my code and dump the contexts of gamecontrollerdb.txt into that. Then I can just use SDL_RWFromConstMem() to create an SDL_RWops and call SDL_GameControllerAddMappingsFromRW() on that SDL_RWops.
When I tried it though, the compiler threw an error “string too big.”
Understandable. The string is… big…
Does anybody have any suggestions on how I can leverage GameControllerDB without being dependent on an external text file?
Thanks for the suggestions. Some interesting ideas here. Maybe a few things I might explore in the future. Especially the SDL_filesystem API.
But the short answer is, it’s complicated. The way the project is structured there is no clear “resources” folder where I can store files that my code will know the relative path to in all install situations. There are reasons for this. They may or may not be good reasons.
There are probably ways to make something like that work, but investing in that direction would take a lot more time than I have to spend on this. The gamepad API is the only thing I’m using SDL for (at the moment). And gameControllerDB is the only external file I need (at the moment). It will be much simpler to get that information into my source code than to invent whole new systems to gracefully handle a “resources” folder in my context.
If I find myself dependent on more and more external files like this I may revisit this thread and consider some of the solutions you’ve proposed.