[clang] [clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)

[Martin Storsjö via cfe-commits]

mstorsjo wrote:

> > I've always kind of held out this idea that clang[++] are perfectly reasonable frontends to use when targeting an MSVC-environment with an official Microsoft Windows SDK
> 
> Me too, but isn't this PR a different idea? This is about using clang with MSVC/Win SDK turned into a Unix-style sysroot, which seems like a much narrower use case.

Yes, exactly. The discussion here conflates a lot of different concepts.

It's perfectly possible to use `clang/clang++` to compile with a Microsoft SDK already, on Windows and cross compiling. The normal method of accessing the SDK (through the `INCLUDE` and `LIB` env variables for specifying locations) works just like it does for `clang-cl` - the flavour of driver doesn't make any difference there.

If you want to manually specify an SDK location instead of passing it through the environment, then you can use the `/winsysroot` option with `clang-cl`. It seems that Clang supports the same option named `-Xmicrosoft-windows-sys-root` with the GNU style `clang/clang++` drivers as well.

This new option isn't about `clang-cl` vs `clang/clang++` driver style, but just about supporting a different kind of SDK layout. If considered useful, the same SDK layout should of course also be usable with `clang-cl` as well. So please isolate the discussion around the SDK layout and skip the other unrelated parts.

> I think it would be better if the driver could work with the MSVC/SDK as-is, rather than forcing the user to change the SDK into a form that the driver likes (even if it's a "standard" form in the sense that other sysroots use it).

This already works, as far as I know - through the `/winsysroot` and `-Xmicrosoft-windows-sys-root` options.

> That would probably require more work, such as supporting case-insensitive includes, but seems like it would be much user friendlier.

Supporting case insensitive includes would indeed be nice.

> Please just merge it since this PR has been over 2 years.

Just because the PR has been up for a long time isn't a reason for cutting the discussion short - especially for something that defines new public interfaces in how Clang interacts with other toolchain components.

https://github.com/llvm/llvm-project/pull/96417