[PATCH] D109185: [gn build] Add build files for LLDB

Wed Sep 8 13:29:41 PDT 2021

thakis added a comment.

In D109185#2988837 <https://reviews.llvm.org/D109185#2988837>, @teemperor wrote:

> Thanks! Out of curiosity, is there a public GN bot that is testing this?

The GN bots at http://45.33.8.238/ do the compile step. They don't yet run lldb tests. Maybe I'll add that, but maybe I'll wait until more of the test suite is brought up.

>> LLDB has many dependency cycles, something GN doesn't allow. For that reason, I've omitted some dependency edges. Hopefully we can clean up the cycles one day.
>
> No idea about GN, but I would assume this would break the build in some form? Or does this just mean ninja doesn't know the dependencies and the build process has a race condition?

The CMake build works around this with the `set_target_properties(lldbCore PROPERTIES LINK_INTERFACE_MULTIPLICITY 5)` hack in lldb/source/Core/CMakeLists.txt.

In the GN build, it means you can't really build the libraries independently. But the binaries build fine (…at least with lld and ld64. It's possible BFD ld needs a --start-group / --end-group around libraries? Haven't tried that yet.)

>> LLDB has a public/private header distinction, but mostly ignores it.
>> Many libraries include private headers from other modules.
>
> Is this referring to some `private-*.h` `public-*.h` files or what are those public/private headers that are incorrectly included?

LLDB has lldb/include/lldb/Foo which (like in the other LLVM projects) are supposed to define a module's public interface from what I understand, while headers in lldb/source/Foo are Foo's internal headers. At least that's how it works in clang and llvm. In lldb, many modules include another module's private headers (in that sense that they're in lldb/source/Foo instead of in lldb/include/lldb/Foo), while that's much less common in llvm and clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109185/new/

https://reviews.llvm.org/D109185