[llvm-dev] Building SVN head with CMake - shared libraries?

[Chris Bieneman via llvm-dev]

Dan,

Thanks for looking so deeply at this. I think the fundamental problem is that we still have our infrastructure in an odd state as we’re moving off autoconf.

Brad’s explanation of the component mappings is correct, but with an added complication that we also have LLVMBuild which handles the dependency connections between static libraries. That allows a user to specify the specific components that their project depends on, and our build scripts will also add any components that those components depend on (see: `llvm_expand_dependencies`).

In our CMake `llvm_config` and `llvm_add_*` serve very different purposes. In general all the functions and macros that start with “${project}_*” are intended as internal to our CMake, and we really don’t encourage others to call them at all. We also have functions and macros that match the pattern "add_${project}_*" which are intended for use only within a given project, those are generally built on top of the “llvm_add_*” functions.

The intention is that out-of-tree clients (like CastXML) would use llvm_config, which would roughly map to the functionality of the llvm-config command line tool that we’ve used with autoconf. All of these code paths end up using “llvm_map_components_to_libnames", for the actual mapping. Part of the problem here is that we haven’t kept the functionality of that function in parity with the llvm-config tool.

Today the llvm-config tool knows which components get put into libLLVM.so, and knows how and when to map to the shared library. I think that is the missing bit of functionality here. I don’t even think adding that will be hard, we just need to make sure that LLVM_DYLIB_COMPONENTS, and LLVM_LINK_LLVM_DYLIB are both saved of in LLVMConfig.cmake.

I may have time to take a stab at this later today.

-Chris

> On Jan 19, 2016, at 6:01 AM, Brad King <brad.king at kitware.com> wrote:
> 
> On 01/17/2016 02:53 PM, Dan Liew wrote:
>> @Brad: CC'ing you because I know you use
>> ``llvm_map_components_to_libnames()`` so you will likely have
>> something to say about it breaking.
> 
> I'm using it in CastXML but that could easily be adapted to something
> different if needed.  The larger concern is that that API is the
> documented way to use LLVM in an application with CMake so there could
> be many such clients.
> 
>> * The way that LLVM components are linked against seems really messy
>> to me. We have this ``llvm_config()`` macro for linking against
>> components but also ``llvm_add_library()`` does this too. We don't
>> need two ways of doing the same thing. I think there should be one
>> clean way of doing this.
>> 
>> * If the static libraries are not installed then external projects
>> that use LLVM via [1] won't build because
>> ``llvm_map_components_to_libnames()`` only works with the static
>> libraries. We need to provide something better that does the right
>> thing automatically but allows forcing to use the static components or
>> the dynamic library.
> 
> IIUC the purpose of asking applications to map component names
> instead of directly naming libraries is so that the set of actual
> libraries can be changed out underneath while retaining the same
> components.  This abstraction means that if only the shared library
> is installed then ``llvm_map_components_to_libnames()`` can simply
> return it for all components built into it.  Its implementation just
> needs to be made conditional on the option for static libraries.
> 
> -Brad
>