Don't use SDL filesystem in DInput joystick driver

[Nintorch]

• I confirm that I am the author of this code and release it to the SDL project under the Zlib license. This contribution does not contain code from other sources, including code generated by a Large Language Model ("AI").

Description

This PR makes the DirectInput joystick driver optionally not use the SDL filesystem subsystem in case an external project that intergrates SDL (e.g. Godot Engine) doesn't use its filesystem subsystem.

Please let me know if this change is acceptable!

Existing Issue(s)

None

[slouken]

I don't mind switching to Win32 filesystem code here, but this isn't equivalent, and won't find e.g. "C:\Windows\USB_Vibration\791847\EZFRD64.DLL"

[Nintorch]

Changed the approach to use where command ran from the command line to simplify the code

[eloj]

I'm sorry, but why are we doing this? Shouldn't the internal use of SDL_GlobDirectory be completely transparent?

[Nintorch]

It's done in case an external project only uses the joystick/gamepad subsystems of SDL and not the filesystem one. So I replaced the filesystem subsystem usage here so external projects don't have to include the filesystem subsystem just for this check, if that's okay.

[eloj]

I'm genuinely unsure how you use this code without the rest of SDL being available. Are you just adding a subset of SDL source files directly to the project instead of dynamically linking against the DLL?

I think adding a system() call here to cover this odd use-case is... not a very good idea.

If there's some sort of integration friction here (i.e why are we picking subsystems / manually including source files), I'd much rather that was addressed instead.

[Nintorch]

What exactly do you mean when you say "include the filesystem subsystem"? Not having to call SDL_QuitFilesystem()?

I'm genuinely unsure how you use this code without the rest of SDL being available. Are you just adding a subset of SDL source files directly to the project instead of dynamically linking against the DLL?

Yes, we do that in Godot to decrease the binary size so we don't have quite a lot of unused code:
https://github.com/godotengine/godot/blob/master/drivers/sdl/SDL_build_config_private.h
https://github.com/godotengine/godot/tree/master/thirdparty/sdl

Similar approach is done in QGroundControl:
https://github.com/mavlink/qgroundcontrol/blob/master/src/Utilities/SDL/CMakeLists.txt
Although they don't exclude the filesystem subsystem.

instead of dynamically linking against the DLL?

See also godotengine/godot#87925 (comment)

• This PR uses SDL as a system library, which assumes that SDL is available on all Linux systems. That's fine for Steam as it's part of the Steam Linux runtime, but it's not a reasonable assumption for general portable Linux binaries. If we want to use SDL, we will probably need to build and link it statically together with Godot.
• If we're building SDL and linking it statically for all platforms, we should assess how much of SDL we actually need to build/include. It might be that we just need to reuse hidapi, or their input code, without pulling in the whole framework.

[Nintorch]

I think adding a system() call here to cover this odd use-case is... not a very good idea.

In this case we can include the filesystem subsystem in Godot, but I think we should wait for slouken's answer

[eloj]

Okay, I understand.

IMO, if you want to do it that way, that's fine; But maintaining that sort of build should fall squarely on Godot's shoulders. This shifts some of the 'burden' back to the SDL project.

I think this is a bad change for SDL, and just looking at it, it doesn't seem very onerous for Godot to just also include the FS code, even if it adds a few KiB.

I've said my piece. Ultimately it's up to Sam and the real maintainers.

[slouken]

We shouldn't add a system() call here. If you want to avoid using SDL filesystem code, that's fine, but you should write custom findfirst/findnext code instead.

[slouken]

... or just link with SDL filesystem code. It's not that big. :)

[Nintorch]

I see, thank you for your answer, I think we will include the filesystem code in Godot, that seems to be the better approach for now! 😅