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

[Ted Woodward via lldb-dev]

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:
>
> -string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> ${LLVM_DEFAULT_TARGET_TRIPLE})
> +string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> +"${LLVM_DEFAULT_TARGET_TRIPLE}")
>
> 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:
>
> #if (${LLVM_DEFAULT_TARGET_TRIPLE})
>   string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> "${LLVM_DEFAULT_TARGET_TRIPLE}")
> #else()
> #  set(LLDB_DEBUGSERVER_ARCH "")
> #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
> "@LLVM_TOOLS_INSTALL_DIR@")  set(LLVM_HAVE_OPT_VIEWER_MODULES
> @LLVM_HAVE_OPT_VIEWER_MODULES@)
> set(LLVM_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@)
> set(LLVM_ENABLE_SHARED_LIBS @BUILD_SHARED_LIBS@)
> +set(LLVM_DEFAULT_TARGET_TRIPLE "@LLVM_DEFAULT_TARGET_TRIPLE@")
>
>  if(NOT TARGET LLVMSupport)
>    set(LLVM_EXPORTED_TARGETS "@LLVM_CONFIG_EXPORTS@")
>
> 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