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 spelling? 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 `Kernel32.lib`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62034/new/ https://reviews.llvm.org/D62034 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
