Shoaib Meenai via llvm-dev
2017-Dec-01 21:41 UTC
[llvm-dev] CMake executable dependency woes
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=
Chris Bieneman via llvm-dev
2017-Dec-01 22:39 UTC
[llvm-dev] CMake executable dependency woes
Ultimately we do need to migrate to the new interface for `target_link_libarires` because some day CMake could (and probably should) deprecate the old syntax. If you're willing to take that task on that seems like the right solution and the best way to move forward. -Chris> On Dec 1, 2017, at 1:41 PM, Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Shoaib Meenai via llvm-dev
2017-Dec-08 02:40 UTC
[llvm-dev] CMake executable dependency woes
To follow up on this, I converted all uses of target_link_libraries for
executable targets to explicitly use PRIVATE in r319840 (along with a bunch of
follow-ups to cover cases that I'd missed initially). There are still lots
of uses of target_link_libraries missing an explicit INTERFACE/PRIVATE/PUBLIC,
and I'm looking into those (they're mostly for static libraries, I
believe); it just requires a bit more thought since using PRIVATE everywhere may
not be correct.
On 12/1/17, 2:40 PM, "Chris Bieneman" <chris.bieneman at me.com>
wrote:
Ultimately we do need to migrate to the new interface for
`target_link_libarires` because some day CMake could (and probably should)
deprecate the old syntax. If you're willing to take that task on that seems
like the right solution and the best way to move forward.
-Chris
> On Dec 1, 2017, at 1:41 PM, Shoaib Meenai via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
> 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
>
>
> _______________________________________________
> 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=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=Ra77APGFFcw-9zjkZ_HI9ahxtfia2dubjzYiIab5thY&s=29DgoCHoB8p_8VnpPNkKsJoHUKa5nQuxFU_hbLiJ_rU&e
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171208/65eb71b0/attachment.html>