output of `/showIncludes` should be lowercased for SDK files about msvc-wine

[mstorsjo]

All SDK files are lowercased after installaiton.

CMake/Ninja uses output of /showIncludes for dependency information.

Currently Ninja keep recompiling when the source code contains uppercase header files, as those files are not exist actually (checked with ninja -d explain).

E.g. most commonly used

#include <Windows.h>
#include <GL/gl.h>

Thanks for the report; for this case I think I add an exception to keep GL/gl.h capitalized in that way.

Overall I don't think we should try to lowercase the output from /showIncludes - that would break dependencies for user code that uses uppercase file names or directories (unless we'd make the lowercasing even more complex by trying to distinguish between what's SDK headers and what's user headers). MSVC actually used to have a bug that did that, see https://developercommunity.visualstudio.com/t/showIncludes-lowercases-some-path-segme/233871 for context.

I guess you might be familiar with the reason for lowercasing the SDK files, but just for clarity - there's two or three reasons, somewhat interlinked:

• The WinSDK headers in the unmodified form aren't self-consistent. E.g. Windows.h as the file is named on disk, but it's mentioned 531 times with the name windows.h while only 7 times as Windows.h. Other headers also have the same issue, and some headers are even spelled in many various forms. This has implications in various forms with respect to the issue you're describing - anytime you'd include a SDK header that included another one with non-canonical spelling, you'd hit this issue.
• While MSVC is case insensitive (thanks to Wine in this case), clang-cl is case sensitive by default, so the headers that are inconsistent would simply not work there. So either they have to be lowercased, or one can configure Clang to use a VFS mapping that makes it case insensitive.
• Mingw based toolchains are case sensitive by default, and they ship mostly lowercase headers. So any code that wants to be compileable with mingw toolchains need to refer to the headers by their lowercase name anyway.

So going forward, the main thing I can recommend is to include them with their lowercase name; that makes your code more compatible with mingw toolchains too.

GL/gl.h is an exception to that, as that's a header that is used with that exact spelling across other case sensitive systems too, and mingw toolchains ship the header with that name as well. So I should make an exception to the lowercasing process to keep that one intact.

Therefore, both due to user code that can use upper case names, and due to exceptions (that aren't handled yet but that I should do) like GL/gl.h, I don't think we should forcibly lowercase the dependency info output.

Another potential workaround is to make ninja case insensitive for such dependencies. I have a patch that does that, but it's not upstreamed and I'm pretty sure they don't want to merge it; see mstorsjo/ninja@ba931c1.

[huangqinjin]

Thanks for detailed clarification! I had never realized these reasons.

add an exception to keep GL/gl.h capitalized

I woud appreciate very much . But I think Windows.h is also worth being an exception too. It is so old a header file with the uppercased name and it is unavoidable for programming for Windows platform. It is hard to change third parties' code, e.g. https://github.com/ocornut/imgui/blob/13931fd8516e0ee8425cf82dc5eca020a76e7b3c/imgui.cpp#L919-L923.

unless we'd make the lowercasing even more complex by trying to distinguish between what's SDK headers and what's user headers

What about adding a new sed expression s|^\(Note: including file:\s*/opt/msvc\)\(.*\)|\1\L\2|

[mstorsjo]

But I think Windows.h is also worth being an exception too. It is so old a header file with the uppercased name and it is unavoidable for programming for Windows platform. It is hard to change third parties' code, e.g. https://github.com/ocornut/imgui/blob/13931fd8516e0ee8425cf82dc5eca020a76e7b3c/imgui.cpp#L919-L923.

We can't leave it uppercased as Windows.h as that breaks all the code that includes it with all lowercase, if using clang-cl. But I guess I could consider making a exception, where we leave a symlink so it's accessible with both names.

On that topic, I guess it's could potentially be possible to leave all headers intact with both all-lowercase and original case by adding symlinks for all of them. Or we could at least make an option for that form.

unless we'd make the lowercasing even more complex by trying to distinguish between what's SDK headers and what's user headers

What about adding a new sed expression s|^\(Note: including file:\s*/opt/msvc\)\(.*\)|\1\L\2|

I'm not really a fan of that; the toolchain can be installed anywhere, and can be moved around freely after being set up.

[huangqinjin]

we leave a symlink so it's accessible with both names

Yeah, that is what in my mind but I didn't express it clearly.

the toolchain can be installed anywhere, and can be moved around freely after being set up

can use the variable?

msvc-wine/wrappers/msvcenv.sh

Line 19 in 635a3aa

BASE_UNIX=$(cd "$(dirname "${BASH_SOURCE[0]}")"/.. && pwd)

[mstorsjo]

the toolchain can be installed anywhere, and can be moved around freely after being set up

can use the variable?

msvc-wine/wrappers/msvcenv.sh

Line 19 in 635a3aa

BASE_UNIX=$(cd "$(dirname "${BASH_SOURCE[0]}")"/.. && pwd)

I guess we could use that variable, but I'd rather not go that way. I guess #61 should be enough to fix the problems you're having?

[huangqinjin]

@mstorsjo Thanks! The PR solved my issue.