[CMake] Avoid libcxxabi dependency when building LLDB from the monorepo on macOS by default

[sgraenitz]

Summary

libc++abi became mandatory to link the libc++ binaries. LLDB only needs the build artifacts and not the linked output (we don't ship libc++.dylib and/or libc++.a). Disable the respective link steps to avoid the dependency to libc++abi.
Commit 1665dd63466b (SVN r365038) set the default in the Apple-lldb-base cache, but it would be good to have this even when not using the cache.

[sgraenitz]

This is a no-op when used in conjunction with lldb/cmake/cache/Apple-lldb-base.cmake. Otherwise it touches the cache at configuration time, which typically causes ninja to re-run cmake before starting the build. I think it's acceptable, given that we do this in other situations too, but it's worth noting that using the cache script is a little more elegant.

[ldionne]

When is LLDBConfig.cmake used? I'm trying to understand when the LIBCXX_ENABLE_SHARED=OFF setting will come into play. Will it influence whether libc++.dylib is built in the monorepo whenever you also happen to build LLDB?

lldb/cmake/modules/LLDBConfig.cmake

79

So when both libcxxabi and libcxx are enabled, we will build libc++.dylib and libc++.a? Why not always disable it?

[sgraenitz]

Thanks for taking a look.

In D64395#1575967, @ldionne wrote:

When is LLDBConfig.cmake used?

Very early in the LLDB config process: https://github.com/llvm/llvm-project/blob/e0a3ee79c5ff/lldb/CMakeLists.txt#L15
Globally, I think LLDB is always configured after libc++. Does libc++ make decisions based on these values?

Will it influence whether libc++.dylib is built in the monorepo whenever you also happen to build LLDB?

Yes, I think so. Adding lldb to LLVM_ENABLE_PROJECTS will disable libc++.dylib globally, ...

So when both libcxxabi and libcxx are enabled, we will build libc++.dylib and libc++.a? Why not always disable it?

... if and only if libcxxabi is not enabled. Thus the restriction.

[ldionne]

In D64395#1575999, @sgraenitz wrote:

Thanks for taking a look.

In D64395#1575967, @ldionne wrote:

When is LLDBConfig.cmake used?

Very early in the LLDB config process: https://github.com/llvm/llvm-project/blob/e0a3ee79c5ff/lldb/CMakeLists.txt#L15
Globally, I think LLDB is always configured after libc++. Does libc++ make decisions based on these values?

libc++ decides to build or not build libc++.dylib/libc++.a based on the value of LIBCXX_ENABLE_SHARED and LIBCXX_ENABLE_STATIC, if that's your question.

Will it influence whether libc++.dylib is built in the monorepo whenever you also happen to build LLDB?

Yes, I think so. Adding lldb to LLVM_ENABLE_PROJECTS will disable libc++.dylib globally, ...

In that case, I'm really not a big fan of this approach. I think it's not good hygiene for another project to be poking at libc++'s build options like that. Those are meant to be set by end-users configuring what they want from libc++ only, not set by other projects in the monorepo. To illustrate, I think it's highly confusing if adding -DLLVM_ENABLE_PROJECTS=lldb suddenly disables the building of libc++.dylib.

I think your problem might fix itself with https://reviews.llvm.org/D63883. What exactly is the problem you're trying to solve?

[sgraenitz]

In D64395#1576738, @ldionne wrote:

libc++ decides to build or not build libc++.dylib/libc++.a based on the value of LIBCXX_ENABLE_SHARED and LIBCXX_ENABLE_STATIC, if that's your question.

Sure. I was wondering whether libc++ makes assumptions based on those flags that would break, if we changed them from the outside later on.

Yes, I think so. Adding lldb to LLVM_ENABLE_PROJECTS will disable libc++.dylib globally, ...

In that case, I'm really not a big fan of this approach. I think it's not good hygiene for another project to be poking at libc++'s build options like that. Those are meant to be set by end-users configuring what they want from libc++ only, not set by other projects in the monorepo. To illustrate, I think it's highly confusing if adding -DLLVM_ENABLE_PROJECTS=lldb suddenly disables the building of libc++.dylib.

I think, the condition reduces the potential harm to an acceptable minimum. But yes I agree, it's not good hygiene. We should advise everyone to use the right flags or caches.

I think your problem might fix itself with https://reviews.llvm.org/D63883. What exactly is the problem you're trying to solve?

Yes, I think that would work. I'll drop that patch for now and wait for your fix.

For people reading this after the fact, please pre-populate your cache with something like 1665dd63466b or pass the flags manually.

lldb/cmake/modules/LLDBConfig.cmake

if(LLDB_BUILD_FRAMEWORK)
   # Set designated directory for all dSYMs. Essentially, this emits the
   # framework's dSYM outside of the framework directory.
   if(LLVM_EXTERNALIZE_DEBUGINFO)
     set(LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin CACHE STRING
         "Directory to emit dSYM files stripped from executables and libraries (Darwin Only)")
   endif()
 endif()
 
+if(APPLE)
+  # Force-disable libc++ link steps to avoid the libc++abi dependency,
+  # if not enabled explicitly in builds from the monorepo.
+  if("libcxx" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "libcxxabi" IN_LIST LLVM_ENABLE_PROJECTS)
+    set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "" FORCE)
+    set(LIBCXX_ENABLE_STATIC OFF CACHE BOOL "" FORCE)
+  endif()
+endif()
+
 if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
   set(LLDB_EXPORT_ALL_SYMBOLS 0 CACHE BOOL
     "Causes lldb to export all symbols when building liblldb.")
 else()
   # Windows doesn't support toggling this, so don't bother making it a
   # cache variable.
   set(LLDB_EXPORT_ALL_SYMBOLS 0)
 endif()