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

[Saleem Abdulrasool via Phabricator via libcxx-commits]

compnerd added inline comments.


================
Comment at: libcxx/docs/BuildingLibcxx.rst:90
   > cmake -G "Visual Studio 14 2015"              ^
           -T "LLVM-vs2014"                        ^
           -DLIBCXX_ENABLE_SHARED=YES              ^
----------------
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.


================
Comment at: libcxx/docs/BuildingLibcxx.rst:104
+however running the tests require being run in an environment with a bash
+shell available, which can be provided e.g. by the MSYS2 project.
+
----------------
mstorsjo wrote:
> compnerd wrote:
> > I believe that the documentation suggestions GNUWin32 for the tools, it would be nice to suggest that for consistency.
> GNUWin32 doesn't supply e.g. bash, and afaik @rnk and others have moved away from setups using only that (and that it isn't enough here). In particular here, running things in a plain cmd shell doesn't work - right now. (It might work after more fixes somewhere, but I'm trying to get the shortest path towards a documented working configuration.)
I really would like to keep the cmd environment support.  I do use that environment for a downstream project.


================
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).
----------------
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).


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

https://reviews.llvm.org/D97166