llvm dev - Dec 2017 - 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=

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

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>