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

[Jim Ingham via lldb-dev]

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.

Jim


> On Oct 30, 2019, at 11:55 AM, Ted Woodward <tedwood at quicinc.com> wrote:
> 
> 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