trcrsired 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.
> > 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). That would probably require more work, such as supporting 
> > case-insensitive includes, but seems like it would be much user friendlier.
> > But I won't block this if there's otherwise strong support for it.
> 
> cross compiling is not a narrow use bro.
> 
> And this PR will allow using libc++ with microsoft sdk too and unfortunately 
> microsoft puts C headers and MSVC STL headers together. Without a UNIX style 
> sysroot that seperates msvc stl headers into a seperate include/c++/msvcstl 
> there is no way to get it work.

in fact i use clang on my android phone to cross compile windows on arm .exe 
binaries and run eith wine every day. It is literally native compilation for me 
at this point.
![Uploading Screenshot_20260821-182549.png…]()


I think the reason you said it is narrow probably because you come from the 
background of big tech such as google which relies on libc++ on windows that is 
fine. But for small devs like me who need toolchains to run on android cross 
compilung is a huge big deal

https://github.com/llvm/llvm-project/pull/96417
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to