labath added a comment.

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

In D68980#1709894 <https://reviews.llvm.org/D68980#1709894>, @amccarth wrote:

> My understanding is that the clang-cl driver does some poking around in the 
> file system and registry to come up with defaults for the compatibility 
> level, locations of the library and platform headers and such, but I believe 
> that happens only if it needs to.  If all those answers are in the command 
> line, it shouldn't bother inspecting the system.


Right, but the tests we are talking about here (e.g. 
SymbolFile/NativePDB/disassembly.cpp) should not need any of that registry 
stuff, should they?

The problem I have with this "workaround" is that it's unlikely to ever get 
fixed if it goes in, and I'd like to clarify the role of build.py in all this. 
E.g., if we are convinced that build.py needs to be used for all clang-cl 
invocations, then a more generic `--target` argument might be in order, so that 
one can later also use it to build arm-windows binaries (as they will likely 
have a similar problem).


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

Reply via email to