[llvm-dev] CMake executable dependency woes

Shoaib Meenai via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 1 13:17:40 PST 2017


(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



More information about the llvm-dev mailing list