[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D54567#1300183, @JDevlieghere wrote:

> Personally I don't think we should differentiate between the lit and dotest suite when it comes to using a custom compiler. The separation between the two suits is mostly the result of what framework is easier to write your test is (or which one you're more familiar with). How hard would it be to have one variable that works for both?


I'm not sure how hard it would be.

One problem is that dotest supports not just choosing a compiler, but choosing multiple compilers, as well as multiple architectures and it runs the test suite over the cross product of all of these.  That's hard to express in CMake.  This is why, for example, people end up subverting it entirely for productionizing test suite runs, such as what you see on the ubuntu bot linked earlier.  It doesn't even use the CMake variables for running the dotest suite, it just has scripts that build command lines and runs them.

There is another issue I'm aware of, which is that some people's compilers have version numbers embedded in the binary name.  Right now the code that uses `LLDB_LIT_TOOLS_DIR` to find the binaries won't handle these cases, because it looks specifically for `clang` and `clang++`, but not, for example, `clang-7.0` or `clang++-hexagon-7.0`.

I do think an iterative approach is better though.  This is already a big change and as this thread (and the previous patch which is what I'm trying to fix) shows, people use things in a lot of different ways so changing something has potential for lots of breakage in subtle ways.  So I still kind of prefer doing things incrementally, letting people tell me what's broken, and then working on a solution.

We could try to converge on the single `LLDB_LIT_TOOLS_DIR` approach for both dotest as well as the lit suite, because having one variable with simple semantics is nice.  But I think we should worry first about getting to a known good baseline and then working incrementally to make simplifications.


https://reviews.llvm.org/D54567