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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
