[lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

Ted Woodward via lldb-dev lldb-dev at lists.llvm.org
Wed Oct 30 11:55:43 PDT 2019

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 :-)

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.

> -----Original Message-----
> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Jim Ingham via
> lldb-dev
> Sent: Wednesday, October 30, 2019 1:37 PM
> To: LLDB <lldb-dev at lists.llvm.org>
> Subject: [EXT] [lldb-dev] 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 <compnerd at compnerd.org>
> Date:   Tue Oct 29 08:20:58 2019 -0700
>     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
>   string.
> 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:
> #else()
> #endif()
> 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/LLVMConfig.cmake.in
> w/llvm/cmake/modules/LLVMConfig.cmake.in
> index 7fdca536c1f..e875e661a02 100644
> --- i/llvm/cmake/modules/LLVMConfig.cmake.in
> +++ w/llvm/cmake/modules/LLVMConfig.cmake.in
> @@ -92,6 +92,7 @@ set(LLVM_TOOLS_INSTALL_DIR
>  if(NOT TARGET LLVMSupport)
> 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.
> Jim
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

More information about the lldb-dev mailing list