These look at a glance to be things that will be built into the lldb binary. Like clang’s default target triple is.
Can they be LLDB_TEST_... ?
(otherwise the command is a lot neater than I’d expected)
Ok I see. It’s not that we couldn’t, but it could lead to a lot of test annotations. In that case I agree that it’s best to stick with as few configurations as possible.
I ask because I use it for API tests from an x86 host to an AArch64 VM. I’m using a host build of lldb, so the clang there won’t cross compile unless I give it a sysroot and all that, which is often harder than pointing at an existing gcc install.
But if we’re going to limit shell tests to clang then maybe it doesn’t make sense to have this global override. At least update the docstring for it, or even change the name. LLDB_TEST_API_TEST_COMPILER ? (I know it’s awkward but I like keeping the LLDB_TEST prefix.
So yeah as long as all these new options are documented on Testing - 🐛 LLDB I think I’m on board.
Though, if we’re limiting ourselves to clang and lld are we implying the latest version or one built from the same sources as the lldb under test? I assume the latter as that avoids the version annotations that Pavel brought up.
This doesn’t seem unreasonable. I imagine most users of this testing configuration are going to be shipping a toolchain and if I was doing that, I’d want everything to match anyway.