mstorsjo requested changes to this revision.
mstorsjo added a comment.
This revision now requires changes to proceed.

No, I don't think this is a good idea.

Like I said, the Windows SDK is not self-consistent, so you cannot use it on a 
case sensitive file system without other case insensitivity fixes anyway. Thus, 
this change breaks things for any existing user with mingw headers (which works 
fine on case sensitive file systems without any fixups), and doesn't make the 
Windows SDK work on a case sensitive filesystem anyway. Once the Windows SDK 
actually is self-consistent so that it works on a case sensitive filesystem, 
I'm sure it's possible to add symlinks to mingw to allow the casing that has 
been decided upon by the Windows SDK by then. But until then, please don't.

As an example, the Windows SDK itself (version 10.0.17763.0) contains 839 
occurrances of `#include <windows.h>` or `#include "windows.h"` with all lower 
case, while it contains 1 (one) occurrance of `#include <Windows.h>`. Now, is 
it easier to change all those 839 occurrances of `windows.h` to `Windows.h` in 
the SDK itself, or conclude that `#include <windows.h>` is the canonical 

The SDK contains 455 headers in total where the casing between file name and 
name used in include directives differs.

In addition, when the linker parses embedded `/defaultlib:` attributes, those 
don't match the actual files either. `msvcrt.lib` contains 
`/defaultlib:kernel32.lib`, while the actual file on disk is named 

  rG LLVM Github Monorepo


cfe-commits mailing list

Reply via email to