stella.stamenova added a comment. In D68980#1709967 <https://reviews.llvm.org/D68980#1709967>, @mstorsjo wrote:
> 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... > > > How do tests like test/Shell/Register/x86*.test work in such standalone > builds then? They use lines like these: > > # XFAIL: system-windows > # REQUIRES: native && target-x86_64 > # RUN: %clangxx -fomit-frame-pointer %p/Inputs/x86-64-gp-read.cpp -o %t > # RUN: %lldb -b -s %s %t | FileCheck %s > > > (The XFAIL for system-windows, at least in this test, when I tried it out, > seemed to relate to the fact that `register read --all` on windows didn't > include all the 32 bit subregisters.) > > If tests already can use such constrcuts, I don't see why we couldn't use `# > RUN: %clang_cl ..`, as lit sets up `%clang_cl` in the same way as `%clangxx`. %clang_cl is where we started before we had build.py. It was over a year ago, so it's possible things have improved. 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
