### Author:  [@cgudrian](https://discourse.cmake.org/u/cgudrian)
#### Post date: [May 15, 2020, 3:10am UTC](https://discourse.cmake.org/t/drive-letter-inconsistency-on-windows-between-find-path-and-implicit-include-directories/1221/1 "2020-05-15T03:10:04Z")
Hello!
On Windows find\_path returns a path with a lowercase drive letter (e.g. “c:/cross-sdk/sysroots/target/usr/include”). The CMAKE\_\\_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.
Is this a bug? Is there a workaround?
Thanks!
Christian
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 15, 2020, 11:31am UTC](https://discourse.cmake.org/t/drive-letter-inconsistency-on-windows-between-find-path-and-implicit-include-directories/1221/2 "2020-05-15T11:31:24Z")
@brad.king Would passing implicit include directories through the get-real-case function alleviate this? Or does that also do symlink collapse/traversal?
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [May 15, 2020, 11:41am UTC](https://discourse.cmake.org/t/drive-letter-inconsistency-on-windows-between-find-path-and-implicit-include-directories/1221/3 "2020-05-15T11:41:49Z")
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.
---
### Author:  [@cgudrian](https://discourse.cmake.org/u/cgudrian)
#### Post date: [May 18, 2020, 3:06am UTC](https://discourse.cmake.org/t/drive-letter-inconsistency-on-windows-between-find-path-and-implicit-include-directories/1221/4 "2020-05-18T03:06:39Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 18, 2020, 12:06pm UTC](https://discourse.cmake.org/t/drive-letter-inconsistency-on-windows-between-find-path-and-implicit-include-directories/1221/5 "2020-05-18T12:06:27Z")
> [@cgudrian](#):
>
> 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.