[lldb-dev] [CMake] LLDB framework / shared library

[Stefan Gränitz via lldb-dev]

Hello Alex, hello Pavel

I spent some time creating/streamlining our CMake infrastructure downstream of LLDB and learned a few things about bundles, versions, code-signing etc. (mostly on the Darwin side of things). I am currently sorting out what can be upstreamed and prepare reviews.

Some work is still todo for the LLDB shared library/framework (for simplicity I will call it LLDB.framework). It would be great to know, if you have concerns or comments on the following points:

(1) The liblldb target builds the actual LLDB.framework, while the lldb-framework target adds headers, symlinks, etc. What is the reason for this separation? Can I merge that into one target with post-build steps?

(2) In previous reviews there was an effort to centralize the code for building LLDB.framework, which makes sense to me. With the current LLDBFramework.cmake approach, however, it’s spread over at least 3 different files (lldb/CMakeLists.txt for init and lldb/source/API/CMakeLists.txt for actual definition). In a similar case downstream, I did all that in a single CMakeLists.txt in the source folder. While I see that LLDBFramework affects the whole project, I don’t see why we need a separate LLDBFramework.cmake (BTW upstream it’s included only once). Do you think I can move things to lldb/source/API/CMakeLists.txt where possible?

(3) Currently the build directory for LLDB.framework is determined from LLDB_FRAMEWORK_INSTALL_DIR, which I think is a little confusing. Can I clean this up? (e.g. having a LLDB_FRAMEWORK_BUILD_DIR)

(4) With Xcode, executables are emitted in bin and copied to LLDB.framework where necessary. CMake emits them into LLDB.framework directly and creates symlinks to bin. With LLVM_EXTERNALIZE_DEBUGINFO on Darwin, this has the effect, that by default their dSYMs will end up in LLDB.framework. Thus, I would prefer the Xcode behaviour here.

(5) Couldn’t (4) also simplify the INCLUDE_IN_SUITE logic? I would consider it to be LLDB.framework’s responsibility to set dependencies and adjust RPATHs for all required artefacts. The tools wouldn’t need to care about that (though, they could still check LLDB_BUILD_FRAMEWORK). The RPATH-login for case ARG_INCLUDE_IN_SUITE && LLDB_BUILD_FRAMEWORK is quite complicated though and I wonder if there are strong reasons not to do that. What do you think?

(6) Just out of interest: why is LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7?

Best
Stefan