[LLVMdev] [RFC] March Update: Progress report on CMake build system's ability to replace autoconf

[Chris Bieneman]

> On Mar 4, 2015, at 12:25 PM, Dan Liew <dan at su-root.co.uk> wrote:
> 
> Hi Chris,
> 
> Thanks for working on this. I haven't been following LLVM for a few
> months and in that time it seems support for building a monolithic
> shared library has been added which is great! I've been looking over
> it and I have a few questions/comments.
> 
> * The LLVM_BUILD_LLVM_DYLIB flag isn't document. I've attached a patch for this.

Patch LGTM. Later today I will also add this to my patches currently under review: http://reviews.llvm.org/D8046 <http://reviews.llvm.org/D8046>

> 
> * I'm not very familiar with export lists so sorry if this is a dumb
> question. I see that one is generated that only has LLVM's C API in
> it.
>  It doesn't look like this file gets installed or used by the rest of
> the build. Who is the intended consumer for this file?

It is consumed by the linker. The linker then uses the export list to determine what symbols are exposed in the final binary.

> 
> * I think there's a difference in behaviour between the
> autoconf/Makefile build system's ``--enabled-shared``
>   and the current implementation. When LLVM is built with
> --enable-shared the llvm tools are linked against the shared
>   library but with LLVM_BUILD_LLVM_DYLIB the tools are still linked
> against the static LLVM libraries. I'm not sure
>   if people really care about this (perhaps distribution package
> maintainers might?).

You’re the first person to mention this. If it is a problem it can be addressed, although it will need to be controlled by flags. Linking the tools against the dylib would mean exporting the C++ API not just the C API, and validating that the dylib is configured to contain all the libraries required by the tool.

Unlike the Makefile build system the CMake build system’s dylib is highly configurable to fit with the needs of embedded clients.

> 
> * The exported LLVM targets [1] which external projects using CMake can use
>   to add LLVM to their project still refers to LLVM's static
> libraries rather than the built
>   dynamic library. Should this be changed? I'm not sure how easy this would be.

The CMake build system’s dylib is highly configurable, so I don’t think this should change.

> 
> * Placing the files for building the shared library in ``tools/``
> feels a bit odd given that its
>  not actually a tool. Is there a good reason for doing this?

I actually don’t know the history of this. llvm-shlib has been in tools before the CMake build system had support for it.

-Chris

> 
> [1] http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project
> 
> Thanks,
> Dan.
> <document_LLVM_BUILD_DYLIB.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150304/b8b34ce5/attachment.html>