Page MenuHomePhabricator

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

Authored by sgraenitz on Jul 9 2019, 3:41 AM.

Details

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.

Event Timeline

sgraenitz created this revision.Jul 9 2019, 3:41 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: mgorny. · View Herald Transcript

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.

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?

Thanks for taking a look.

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.

Thanks for taking a look.

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 abandoned this revision.Jul 9 2019, 1:05 PM

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.