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

[Chris Bieneman]

On Mar 4, 2015, at 3:34 PM, Dan Liew <dan at su-root.co.uk> wrote:

>> * 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.
> 
> Sure it's not a problem for me but I suspect someone wanting to keep
> the their LLVM toolchain binaries as small as possible might want the
> binaries to all link against the shared library rather the static
> libraries. Maybe when the switch happens someone will chime in but for
> now it's probably best to leave this.

I'm currently not looking at this, but I expect it will be something my team will want next year. I may look into it sooner rather than later.

> 
> Out of curiosity is there a flag that causes all symbols to be
> exported (i.e. no version script is passed to the linker)? I couldn't
> see one.

No, but we will need one if we support linking the tools against the dylib.

> 
>> 
>> * 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.
> 
> I'm not quite sure what you mean. Sure the system is configurable but
> not to the extent that clients of LLVM have control over what is
> returned by ``llvm_map_components_to_libnames()``. AFAICT this will
> always give the static libraries which a client of LLVM might not want
> (especially if the distribution that ships LLVM removes the static
> libraries and only ships the dynamic library). They might want the
> dynamic library instead.

Yes, but I don't think we currently encode which LLVM components the dylib contains in the exported CMake config files, so we don't properly know when you can use the dylib vs when you need to fall back to static libs. One of the side effects of the dylib being configurable is that it isn't a blanket replacement for all the static libs.

> 
> This would be a little challenging to implement though because it
> might not be so easy to know if an the installed LLVM dynamic library
> was built with the components that the caller of
> ```llvm_map_components_to_libnames()`` asked for.

Exactly. I have some ideas here though.

> 
>> 
>> * 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.
> 
> That might be an artifact of the autoconf/Makefile build system to
> ensure that all components are built before trying to build the shared
> library.

That would make a lot of sense, and there is a similar requirement for the CMake system. I was actually planning to look into whether or not we could make a combined LLVM/Clang dylib for one of our internal clients, which would also make having this be a tool convenient.

-Chris

> 
> Thanks,
> Dan.