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 <tedw...@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-boun...@lists.llvm.org> On Behalf Of Jim Ingham via
>> lldb-dev
>> Sent: Wednesday, October 30, 2019 1:37 PM
>> To: LLDB <lldb-dev@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 <compn...@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@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
