Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

Hi, all...

Saleem submitted a patch to work around some other changes in llvm cmakery that was making LLVM_DEFAULT_TARGET_TRIPLE undefined when lldb went to use it for the macOS debugserver build.

That was:

commit 55eec2ba96bd9c19ccb5d4d13cb8c88d4abcebc6
Author: Saleem Abdulrasool <>

    build: workaround stale caches (NFC)
    `LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
    may actually be unset. Furthermore, in standalone builds, the variable
    may be fully undefined. Apply the regular expression over the empty
    string in such a case. This should improve the state of the green
    dragon bot.

But that change:


didn't work. If LLVM_DEFAULT_TARGET_TRIPLE is not set, then CMake fails with:

CMake Error at tools/debugserver/source/MacOSX/CMakeLists.txt:13 (string):
  string sub-command REGEX, mode MATCH regex "^[^-]*" matched an empty

and the generation stops.

It seems weird to me that successfully matching against an empty string is an error, I'd think you would copy an empty string to the target variable. But my knowledge of CMake pretty much stops at "the C and the M are capitalized, the rest aren't..."

Anyway, another way to do this would be something like:


Which would then dial up the default architecture (x86_64) further on. But Vedant thought instead of this, it would be more generally useful to assure that LLVM_DEFAULT_TARGET_TRIPLE was exported, like:

diff --git i/llvm/cmake/modules/ w/llvm/cmake/modules/
index 7fdca536c1f..e875e661a02 100644
--- i/llvm/cmake/modules/
+++ w/llvm/cmake/modules/


I'm a little hesitant to propose this change as I don't have a good sense of the ramifications of doing this, or why it wasn't done this way to begin with.

LLVM_DEFAULT_TARGET_TRIPLE seems like an oddly named variable to use for the host OS that we're building for. If I build an x86_64-darwin hosted compiler but only included the arm backend, it would be odd to have the default target triple be x86_64-darwin, so I'm surely missing something...

Anyway, so I wanted first to float the question here before suggesting a change.


Except of course without the comment markers...

I'm not going to comment on the change (my cmake knowledge is a hair more than yours, but not enough for this), but LLVM_DEFAULT_TARGET_TRIPLE is the default backend. LLVM_HOST_TRIPLE is the triple we're running on. In your example, LLVM_DEFAULT_TARGET_TRIPLE should be something like arm-apple-darwin and LLVM_HOST_TRIPLE should be something like x86_64-apple-darwin. I'm not sure what the exact triples are :slight_smile:

When we build Hexagon tools, LLVM_DEFAULT_TARGET_TRIPLE, LLVM_TARGET_ARCH and TARGET_TRIPLE are hexagon-unknown--elf. LLVM_HOST_TRIPLE is either x86_64-unknown-linux or x86_64-pc-windows.

Yeah, I take that part back. It sort of makes sense that you build the server for the architecture you are building binaries for, since the server has to run wherever the binaries run. If we were being strict about that, we'd build one server for each backend we build clang for, but we don't do that. So maybe this is the best guess for what the builder intended. This was a side comment, and not the main question.