stella.stamenova added a comment. In D68980#1709931 <https://reviews.llvm.org/D68980#1709931>, @labath wrote:
> In D68980#1709884 <https://reviews.llvm.org/D68980#1709884>, > @stella.stamenova wrote: > > > The two things that come to mind are the path to clang-cl (which is > > sometimes a clang build and sometimes installed on the system as part of a > > VS installation or an LLVM installation) as well as the path to the linker > > when it is needed. This is most often an issue in the case of a VS install > > - I don't remember all the details any more, but I believe that before Zach > > added the script, we were often picking up the wrong clang-cl and ending up > > not being able to compile the tests at all. > > > Thanks. > > Was this during a standalone lldb build? In a non-standalone build, lit > should definitely prefer the just-built clang/lld (and if it doesn't, it > should be fixed to do that). The situation is more complicated for a > standalone build because the clang binary is sort of out of our control. But, > in this case, I don't see how having build.py around can help, because the > information about which clang to use has to come externally anyway... Both. Again, it's been a long time, but when we use VS for building, the environment already contains a path to clang-cl so regardless of whether the build is standalone or not, the build gets confused about which clang-cl to use. @mstorsjo might want to update the tests to use clang-cl but then make sure that the update works on the Windows Buildbot (or similar environment) before committing. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68980/new/ https://reviews.llvm.org/D68980 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
