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

[Reid Kleckner via Phabricator via libcxx-commits]

rnk accepted this revision.
rnk added a comment.

lgtm in any case, this is an improvement.



================
Comment at: libcxx/docs/BuildingLibcxx.rst:111
+`\msys64\msys2_shell.cmd -full-path -mingw64` (preserving the earlier
+environment, allowing the MSVC headers/libraries and clang-cl to be found).
 
----------------
mstorsjo wrote:
> @rnk - Does this match how you generally build/run tests for other llvm components these days, or do you use some other provider of a unix shell, or do the rest of the tests cope with just a plain cmd shell?
> 
> At least for the libcxx tests, running tests in a cmd shell errors out like this:
> ```
> Script:
> --
> echo 'COMPILED WITH' > nul &&  'C:/Program Files/LLVM/bin\clang++.EXE' ...
> 
> --
> Exit Code: 9009
> 
> Command Output (stderr):
> --
> ''C:' is not recognized as an internal or external command,
> operable program or batch file.
> 
> ```
Yes, this is pretty close to what I do. I usually develop in bash, and then bash is on PATH, and most lit tests succeed that way. The codepath where lit invokes cmd to run tests is not maintained, and should ideally be removed.

However, you are probably aware that all of the other lit test suites in LLVM avoid the use of a shell altogether, instead using the lit internal shell. At the time, skipping the extra shell subprocess in every test saved a lot of time for me, so I put a fair amount of effort into migrating to the internal shell. It might be worth doing the same for libc++, but I haven't looked into it at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97166