The purpose of this directory in GLFW is to provide some headers that
"mingw.org" doesn't. Raylib has long been unable to build with mingw.org
due to using certain symbols that aren't exposed in their headers.
(_ftelli64 and _access, among others.). Mingw-w64 already has the
necessary headers included, and doesn't need any of these external
implementations. For some reason, this also causes the following error
when building with Visual Studio's clang:
clang -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing -std=c99 -O1 -Werror=implicit-function-declaration -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw
In file included from rglfw.c:61:
In file included from ./external/glfw/src/init.c:30:
In file included from ./external/glfw/src/internal.h:331:
In file included from ./external/glfw/src/platform.h:31:
In file included from ./external/glfw/src/win32_platform.h:70:
external/glfw/deps/mingw\xinput.h:227:26: error: a parameter list without types is only allowed in a function definition
227 | void WINAPI XInputEnable(WINBOOL);
|
If the last -Iexternal/glfw/deps/mingw is removed, the build works fine.
So, this workaround causes other problems, while not actually helping
raylib.
0bb605cd79/src/CMakeLists.txt (L272-L279)
GLFW's CMakeLists.txt first checks if either dinput.h or xinput.h are
provided by the toolchain, before telling the compiler to search for
headers in that directory. For EVERY compiler that can build raylib,
this is true.
In summary: This directory causes issues when building with some
compilers, and every toolchain that needs this workaround can't build
raylib anyway.
31c6a340ab