| Issue |
161400
|
| Summary |
[clang] [windows] Clang could offer a case-insensitive header search mode to ease cross-compilation
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
rnk
|
One of the challenges in cross-compiling for Windows is that the Microsoft SDK headers are not always included with consistent or correct case. The preferred name of the file on disk could be `windows.h`, but it may often be referred to as `Windows.h`. Today, users work around this either by post-processing the SDK with scripts to lower-case everything, or by using [`ciopfs` mounts](https://www.brain-dump.org/projects/ciopfs/), (Case Insensitive On Purpose FS). These solutions work, but they require significant setup, and many SDKs are not considered redistributable, so everyone cross-compiling for Windows has to rediscover these solutions.
If would be nice if:
1. Clang had a case-insensitive header search mode for specific directories. Global insensitive lookup seems bad for portability.
2. We used it with `/winsysroot` or any other flag we come up with for pointing Clang at well-known Microsoft SDKs
This seems like it would be easy to implement if we cache directory contents already, since it's a matter of lower-casing filenames when building the in-memory lookup tables, but if we pass all the requests through to the filesystem, it would be a pain.
If we don't already cache directory entries in memory, we should consider doing it, because header search has been known to be a bottleneck in the past. The challenges to doing that are unenumerable directories, i.e. vfs/N where N can be any positive integer, and large directories, where it's not feasible to hold all directory entries in memory.
Another potential challenge is navigating the VFS abstraction layer.
This came up in [this PR](https://github.com/llvm/llvm-project/pull/96417#issuecomment-3350250348), and it's not the first time we've had this conversation.
cc @mstorsjo @sharadhr @compnerd
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs