[LLVMdev] Long-Term Support for LLVM Projects Extension to Build System?

[Chris Bieneman]

> On Jun 22, 2015, at 12:28 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 22 Jun 2015, at 02:42, Dan Liew <dan at su-root.co.uk> wrote:
>> 
>> AFAIK the exported CMake targets only work with the static LLVM
>> libraries right now. The intention is that user's of LLVM should use
>> the llvm_map_components_to_libnames() function in CMake. Right now
>> that returns the names of the static library targets. In principle I
>> suppose it could be modified to return the shared library target
>> instead if a shared build was done. But there are a few issues to
>> consider here:
>> 
>> * When LLVM is built it possible to pick what components go into the
>> shared library which means in some cases
>> ``llvm_map_components_to_libnames()`` would not work as intended if
>> just returns the LLVM shared library target name.
>> * A user of LLVM may want the ability to pick the static libraries
>> even though the shared libraries were built.
>> * In the shared library the C++ symbols hidden so we would need to add
>> an option to disable this behaviour.
>> 
>> Here's what I'd like to suggest:
>> 
>> - Modify ``llvm_map_components_to_libnames()`` to take an optional
>> keyword which is either STATIC or SHARED. To avoid ambiguity this
>> means we cannot have a component called "STATIC" or "SHARED", I don't
>> imagine this would ever happen in practice. So the signature would
>> look like this
>> 
>> llvm_map_components_to_libnames(OUTPUTVAR [STATIC|SHARED] component0 ...)
>> 
>> 
>> - If set to static the static library names will be returned if the
>> components exists, otherwise emit an error message.
>> - If SHARED is specified CMake will check that the requested
>> components were added to the shared library when it was built. For
>> this to work the names of the components will need to be written into
>> LLVMConfig.cmake. If all the components requested are supposed to be
>> in the shared library then return the shared library target, otherwise
>> emit an error message (this includes the case where the shared library
>> was not built).
>> - If STATIC or SHARED is not specified use STATIC so as to not break
>> the interface for existing users of llvm_map_components_to_libnames().
>> - Switch C++ symbol hiding in the shared library off by default.
>> 
>> Thoughts?
> 
> This all sounds great to me.  That said, my use case is quite unusual: I want a single debug build of LLVM and a single release build on a shared file server so that students can link things against a debug build without ending up with a few hundred MBs of object code in their home directories for each exercise and hitting quota issues.  I suspect that this isn’t a problem that doesn’t affect most other people.

If you’re building this for students there is a much simpler way to do this, with the existing build system.

Configure LLVM with a command like this:

cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_OPTIMIZED_TABLEGEN=On -DLLVM_TARGETS_TO_BUILD="X86;ARM;AArch64" -DLLVM_BUILD_LLVM_DYLIB=On -DLLVM_DYLIB_EXPORT_ALL=On -DCMAKE_INSTALL_PREFIX=<install path> <path to llvm>

Setting the install prefix will result in you having a directory you can tar up and send to your students.

Build just the bits you need:
ninja LLVM

Install only the dylib and the headers:
ninja install-LLVM installhdrs

This will give you a working libLLVM that your students can link against, and the headers they need in the most reduced capacity. No need to use CMake, no need to rely on our build system. Much simpler.

You may need to check tools/llvm-shlib/CMakeLists.txt to make sure it has all the LLVM components you need in the default configuration. If it doesn’t you can change the list of components to include in the dylib by setting LLVM_DYLIB_COMPONENTS.

-Chris

> 
> David
>