[libcxx-commits] [PATCH] D97166: [libcxx] [docs] Update docs about how to build for Windows

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/docs/BuildingLibcxx.rst:90
   > cmake -G "Visual Studio 14 2015"              ^
           -T "LLVM-vs2014"                        ^
           -DLIBCXX_ENABLE_SHARED=YES              ^
----------------
compnerd wrote:
> mstorsjo wrote:
> > mstorsjo wrote:
> > > mstorsjo wrote:
> > > > rnk wrote:
> > > > > I'm not sure what this should be. =/
> > > > I'll see if I can try actually running this config - I don't really see it as something that is used much, but I wouldn't want to remove it either.
> > > @compnerd - WDYT about the section in generating VS project files at this point - is it worth keeping (with updated version numbers) - is it something people do, or should we scrap it (as I'm adding a couple other configs here anyway)?
> > Ok, with VS 2017, with a now discontinued VS extension, this should be `-T LLVM` (not tested myself). With VS 2019, with integration shipped as part of Visual Studio itself, this parameter should be `-T ClangCL`. I think I'll update the doc with the 2019 approach.
> Im not too worried about the VS path really.  It would be nice to keep it, but if we cannot, we can remove it with a note saying that we would be accepting of patch to get MSVC as an IDE working.  Personally, I just use CMake + Ninja as the builder and use vim for editing.
I kept this section for now by updating it to a config that I could test that seemed to work, but as you say, it's not a config I'd expect to be used much in practice.


================
Comment at: libcxx/docs/BuildingLibcxx.rst:110
+path. From there, launch an MSYS2 shell via e.g.
+`\msys64\msys2_shell.cmd -full-path -mingw64` (preserving the earlier
+environment, allowing the MSVC headers/libraries and clang-cl to be found).
----------------
compnerd wrote:
> mstorsjo wrote:
> > mstorsjo wrote:
> > > mstorsjo wrote:
> > > > compnerd wrote:
> > > > > I think it would be better to just use `path %PATH%;%ProgramFiles%\Git\usr\bin` as git is also provided by MSVC, and is going to be needed to clone the projects, so it avoids an additional dependency.
> > > > Hmm, maybe, that's worth a try. That would at least provide bash, but it remains to see if it hooks that up the right way, with all the interactions between python/llvm-lit and everything.
> > > That kinda seems to work, but breaks for other reasons. Some later bit tries to execute the python interpreter, and falls down due to incorrect quoting of parts of `C:\Program Files (x86)\Python...`
> > > 
> > > So while it'd be nice, I'll stick with documenting this configuration that works right now (at least after landing D97167, D97168 and D97294).
> > > 
> > > I'll update the patch in any case with a bit more clarifications to help others reproduce the setup, and the other suggestions handled.
> > Actually, it does work with a python installed to a path that doesn't contain spaces (e.g. `C:\Users\Administrator\AppData\Local\Programs\Python\Python39` works, but `C:\Program Files\Python..` doesn't).
> > 
> > I'll try to mention both approaches in the doc.
> Actually, the path with spaces is good to test - we should identify where it breaks, it sounds like a bad lit substitution (missing quotes).
Yeah I fixed that one in D97369 (now merged), so it does run fine in plain cmd now - the current version of this patch now showcases how to do it by adding the Git for Windows binaries to the path, but also mentions how to do it with MSYS2 and mentions the quirks one could run into there. Please have a look at the latest version of this patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97166/new/

https://reviews.llvm.org/D97166