Forum Discussion
Possible bug: Case-sensitive Windows-includes
I am currently working on a multi-platform project in Linux, which I can successfully cross-compile for Windows - until I try to add LibOVR. The problem I encounter seems to be a trivial, yet annoying one:
LibOVR includes "Windows.h", which is not found as the mingw-libraries spell it "windows.h".
While this does not matter at all for Windows developers on a Windows file system, Linux file systems are case-sensitive and I will now either have to fix all the includes in LibOVR (as a fixed windows.h is followed by WinSock2.h) or the mingw library.
As I expect, that there in fact is a "correct" spelling even in Windows, I am wondering if this is an error of mingw or if it is an error in the SDK. (If so, I'd like to file a bug report, please ;) )
LibOVR includes "Windows.h", which is not found as the mingw-libraries spell it "windows.h".
While this does not matter at all for Windows developers on a Windows file system, Linux file systems are case-sensitive and I will now either have to fix all the includes in LibOVR (as a fixed windows.h is followed by WinSock2.h) or the mingw library.
As I expect, that there in fact is a "correct" spelling even in Windows, I am wondering if this is an error of mingw or if it is an error in the SDK. (If so, I'd like to file a bug report, please ;) )
2 Replies
- The file is called Windows.h in the microsoft platform sdks.
So LibOVR has it right.
Although if LibOVR was changed to windows.h, then it would work on Mingw (which has the wrong case) and visual studio (which doesn't care). - ok, if Windows.h is the correct one, than LibOVR should stick to this. Otherwise we will sooner or later stumble upon another tool which then conflicts with the lower-case version.
I am considering to give up on cross-compiling anyway... Each problem I solve seems to lead to two new problems...
