3 minor compatibility fixes

[kala-telo]

• The first commit fixes the warning/error -Werror=format on 32-bit platforms.
• The second commit defines _POSIX_C_SOURCE, which is the portable/intended way to define posix version, but also keeps __USE_POSIX199309. The latter macro, from what I can tell, is internal to GLIBC. I would've removed it completely, but then it breaks examples while compiling on GLIBC, due to stdio.h and other parts of standard library being included before _POSIX_C_SOURCE definition. So to avoid breaking examples(and probably someone else's code), __USE_POSIX199309 is kept. If I were to choose, I would remove it in the next major release, but maybe it is a good idea to keep it as is for compatibility.
• The third commit adds -D RGFW_WAYLAND to RGFW.c flags via LIBS, so it wouldn't try to include X11/extensions/Xrandr.h.

[ColleagueRiley]

Because of RGFW's nature as a single header library, it's fairly hard to enforce a posix standard without forcing the user to use RGFW in a specific way. I want to try to avoid that, which unfortunately leads to issues such as this.

[ColleagueRiley]

The third commit adds -D RGFW_WAYLAND to RGFW.c flags via LIBS, so it wouldn't try to include X11/extensions/Xrandr.h.

"so it wouldn't try to include X11/extensions/Xrandr.h." Shows me that you are thinking about issues in a very surface level way. Xrandr is being included because RGFW is using the X11 backend, because -D WAYLAND is not defined. XRandr has nothing to do with the issue. It's simply that it's dropping the wayland backend in this case.

[ColleagueRiley]

I don't really like this fix because this also adds other files into the command unnecessarily

[kala-telo]

I thought about separating it into it's own variable, but decided against, since I don't think libs affect .o file in any way.

[ColleagueRiley]

Feel free to test it and let me know, I personally think separating it into it's own variable might be the way to go.

[kala-telo]

The third commit adds -D RGFW_WAYLAND to RGFW.c flags via LIBS, so it wouldn't try to include X11/extensions/Xrandr.h.

"so it wouldn't try to include X11/extensions/Xrandr.h." Shows me that you are thinking about issues in a very surface level way. Xrandr is being included because RGFW is using the X11 backend, because -D WAYLAND is not defined. XRandr has nothing to do with the issue. It's simply that it's dropping the wayland backend in this case.

I simply quoted the error message, I understand the issue. Maybe I should've phrased it better.

[ColleagueRiley]

If you're going to make a PR fixing an issue I want more than quoting an error that has nothing to do with the root of the issue. I'm sorry if that sounds harsh but I have found a lot of frustration when reviewing other's code or trying to understand issues others are facing comes down to the difference in thought process.

[ColleagueRiley]

The OSX issue can probably be fixed by changing from usleep to nanosleep or even sleep because that seems to be a function OSX has

[kala-telo]

Because of RGFW's nature as a single header library, it's fairly hard to enforce a posix standard without forcing the user to use RGFW in a specific way. I want to try to avoid that, which unfortunately leads to issues such as this.

I think having both _POSIX_C_SOURCE and __USE_POSIX199309 might be a good and somewhat neutral way to handle that.

If you're going to make a PR fixing an issue I want more than quoting an error that has nothing to do with the root of the issue. I'm sorry if that sounds harsh but I have found a lot of frustration when reviewing other's code or trying to understand issues others are facing comes down to the difference in thought process.

Sorry, I will try to word my reasoning better next time.

The OSX issue can probably be fixed by changing from usleep to nanosleep or even sleep because that seems to be a function OSX has

I'm not experienced with OSX, but adding #define _XOPEN_SOURCE 500 seems to work as well. Is there any preferred way?

Edit: usleep seems to be deprecated, so I guess nanosleep is preferred.

[ColleagueRiley]

I think having both _POSIX_C_SOURCE and __USE_POSIX199309 might be a good and somewhat neutral way to handle that.

Yeah, that seems to be true. It's not a very satisfying fix unfortunately.

[kala-telo]

From what I can tell, defining __USE_POSIX199309 on OSX has no effect, since it's a glibc specific macro. And defining _POSIX_C_SOURCE disables features specific to OSX, so to me it looks like the most reasonable solution is to not define anything.

[kala-telo]

Also there seems to be a rule in Makefile for building examples/every_api/every, which seems to not exist. I decided to still add DEFINES to it, but maybe it should be removed?

[ColleagueRiley]

Looks good. I think examples/every_api/every was either not properly added and accidentally included a year or so ago, or it was removed and I forgot to clean it up