On Windows find_path returns a path with a lowercase drive letter (e.g. “c:/cross-sdk/sysroots/target/usr/include”). The CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES variables however contain upper case drive letters (e.g. “C:/cross-sdk/sysroots/target/usr/include”).
If find_path happens to find a file in such an implicit include directory, this directory gets added to the compiler command line nonetheless. In case of imported targets this happens by default using the “-isystem” flag which then breaks GCC’s include path search order.
@brad.king Would passing implicit include directories through the get-real-case function alleviate this? Or does that also do symlink collapse/traversal?
The implicit include directory filtering should use a path-conventions-aware comparison rather than a raw string compare, at least on Windows hosts. That way it could account for case differences anywhere in the path.
I’ve managed to work around this issue by making sure, CMAKE_SYSROOT uses an uppercase drive letter. But things are more complicated. Using case-insensitive path comparison on Windows might be wrong as well, as it is possible to enable case-sensitivity per directory.
CMake currently assumes case sensitivity is a per-platform decision. So CMake doesn’t really work with case sensitive directories on Windows (same with case sensitivity on macOS, vfat on Linux, and ext4 per-directory case sensitivity flags on Linux). Without a way to reliably have the kernel resolve case sensitivity differences for us, it’s going to be too hard to add to CMake. Every directory access would need to check the real casing, use it, then we have to remember the flag and invalidate it if the directory changes at all. It’s just too much work to plumb that through the codebase.