No Joy(stick): How to get rid of all the mappings.h strings?

My code doesn’t call any of GLFW’s joystick-related functions, and I promise my users won’t even be using one when running my application. So, is there a way to keep all those big strings in mappings.h from cluttering up my linked executable? On all platforms? Thanks for any advice.

I don’t think there is a build option for this. Altering mappings.h to remove them might work if you don’t run the generate mappings step, which I think uses as the input, so altering that and running the generation would also work.

This is a reasonable request to create a GLFW issue for. If you’re unfamiliar with how to create an issue I can do this for you later.

Thanks, a fine work-around (though of course then I can’t use’s downloadable libglfw.a files, and I will have to do battle with cmake).

In my personal nirvana, all of the joystick-related code in input.c would be exiled to a newly-created joystick.c, which would also be where mappings.h got included. As a separate joystick.o in libglfw.a, none of the joystick code or data would be linked into my executable, since none of its symbols would be referenced from my code. Of course, this would mean that the initialization function that reads through the mappings.h data would also have to be lazily called, rather than from the main glfw init routine.

The advantage of bothering with this is that all glfw apps that don’t use a joystick would automatically get smaller. I’m guessing that this would be a significant percentage of them, but what do I know? So, please do create an issue for this if it would be useful for the community.

Being a non-joystick person, I regret that there’s no way I’d be able to contribute a reliable implementation.

[For completeness: Maybe there are (more?) folks who only use joysticks, and have the exact wish on the flip side: All keyboard / mouse code should go into separate .c files so they don’t clutter up joystick-only apps. Then again, at least there aren’t big data tables for the keyboard / mouse code, and smart linkers may be more able to drop individual functions that aren’t called, so it would end up being a useless effort.]