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
