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

[Dan Liew]

> * 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.

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.

>
> * 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.

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.

>
> * 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.

Thanks,
Dan.