[lldb-dev] [OS X]: building lldb with cmake

[René J.V. Bertin via lldb-dev]

On Friday September 09 2016 10:34:37 Greg Clayton wrote:

Hi,

>The biggest issue with trying to use cmake on macOS is that there is no support for building frameworks, please correct me if I am wrong. The xcode build will build a "LLDB.framework" that contains all headers and the shared library, and the "lldb" command line tool that links against that. We really want the LLDB.framework since it gives us a bundle like directory that contains everything we need. 

That may not be supported by the current cmake system, but cmake definitely supports the possibility as pointed out by Zachary.
However, it's not an issue for MacPorts. In fact,

>Current the LLDB.framework contains:
>- LLDB headers
>- clang headers needed for expression compilation where the compiler parses modules
>- associated binaries needed for debugging (lldb-server, lldb-argdumper, debugserver, darwin-debug
>- Python module and packages

This is may be an issue with MacPorts. I haven't looked at that.

Since you mention it: the other parts of LLVM and Clang aren't built as frameworks, correct? If Xcode were to include an llvm-config utility, would it point dependents to the correct locations inside the framework(s)?

>- XPC services for debugging as root

>
>I believe the normal cmake build just will build a lldb.dylib or lldb.so instead of a LLDB.framework. Then you would need to find a place for all of the remaining stuff just like you have to do on linux. 

Indeed. And that just works without any problem at all; the stuff all gets installed into ${prefix}/libexec/llvm-${branch}.

>
>With MacPorts, do all projects tend to not build frameworks, or do some build frameworks?

Some build frameworks, but as a general rule of thumb one can say that cross-platform software is built and installed as it would on any other Unix system. That's the best guarantee that the largest selection of dependent software will also build.

Example: Qt builds frameworks even under MacPorts, just to be sure we install .dylib symlinks to the framework binaries (which AFAIK are redundant nowadays). But all of KDE builds regular shared libraries that link to the Qt frameworks without a glitch. To make things even more "perverse": Qt installs a range of plugins, which go into standard XDG-compliant locations.

R.