[llvm-dev] CMake executable dependency woes

[Shoaib Meenai via llvm-dev]

I discovered that I can hack around my particular problem by placing

set_property(TARGET clang PROPERTY INTERFACE_LINK_LIBRARIES)

at the end of tools/driver/CMakeLists.txt. I'd prefer to fix this properly though,
of course.

On 12/1/17, 4:18 PM, "llvm-dev on behalf of Shoaib Meenai via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote:
    (accidentally sent the previous one to llvm-commits instead of llvm-dev, sigh)
    
    Hi all (CC beanz for CMake advice),
    
    I stumbled into an issue with LLVM_DISTRIBUTION_COMPONENTS. The simplest way
    to reproduce is to run a configure with `-DLLVM_DISTRIBUTION_COMPONENTS=clang`.
    This should show lots of errors of the following form:
    
    CMake Error: install(EXPORT "ClangTargets" ...) includes target "clang" which requires target "LLVMAArch64CodeGen" that is not in the export set.
    
    The issue is that we add dependencies to executables using the legacy
    target_link_libraries signature, which marks the dependencies as public (i.e.
    they apply to both the target and any other targets linking against it, or in
    other words they're interface dependencies). CMake requires install(EXPORT) to
    also export all interface dependencies, which seems like a reasonable
    requirement.
    
    I wasn't running into this previously since I was using LLVM_INSTALL_TOOLCHAIN_ONLY,
    but I need to install some non-tools. I definitely don't want to install all
    of them, however, and I'm building with the default (static library)
    configuration, which makes installing most libraries pretty unnecessary
    for my use case.
    
    My preferred solution would be to mark all dependencies of an executable
    target as PRIVATE, since I don't think interface dependencies make much sense
    for an executable. I hacked this in locally for clang and confirmed that it
    made the install(EXPORT) CMake errors go away. Unfortunately, cmake also
    requires all instances of target_link_libraries for a particular target to use
    either the legacy or the non-legacy signature, and it turns out all our uses
    of target_link_library for executables are using the legacy signature right
    now, so this would have to be a substantial cross-repository change in order
    to avoid breaking the world. I'm fine with taking the work on, but I wanted to
    confirm my approach before putting that work in.
    
    Thanks,
    Shoaib
        
    _______________________________________________
    LLVM Developers mailing list
    llvm-dev at lists.llvm.org
    https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=f6-g5HvD04ut7NY1NTQwMMELINjT5njGhoVCW_nK8sQ&s=cPS_l2TQRkE92HA_YgTcHxl4Jm1FJnAfpdZXATwUrhw&e=