[cmake-developers] Setting the link interface and dependencies in one command

Stephen Kelly steveire at gmail.com
Thu Oct 6 20:01:06 EDT 2011


Brad King wrote:

> On 10/5/2011 9:47 AM, Stephen Kelly wrote:
>> Thanks for all of your explanations. It seems that introducing a way to
>> do this with one command has some support.
>>
>> So if SOME_FEATURE is true,
>>
>> target_link_libraries(foo bar SOME_KEYWORD baz)
>> if (SOME_FEATURE)
>>    target_link_libraries(foo mar SOME_KEYWORD maz)
>> endif()
>>
>> would have to result in bar and mar not being part of the link interface,
>> and baz and maz being part of the link interface.
>>
>> How do we decide on a keyword there? LINK_INTERFACE_DEPENDENCIES perhaps?
> 
> One possible problem with making it a keyword is that the name could
> appear in a list of libraries and invisibly transform a
> target_link_libraries call. 

Do you mean a library or target called LINK_INTERFACE_DEPENDENCIES? Or do 
you mean like this:

  target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})

where the variable could be a list containing the term 
LINK_INTERFACE_DEPENDENCIES?

> What we need is a pair of keywords to switch
> between link+interface and
> link-only dependencies.  We allow the keywords only if one of the two is
> the second argument to the command after the target name.  For example,
> they can be called "LINK_INTERFACE" for link+interface and "LINK_DEPENDS"
> for link-only:
> 
>    target_link_libraries(foo LINK_INTERFACE bar LINK_DEPENDS baz)
>    if(SOME_FEATURE)
>      target_link_libraries(foo LINK_INTERFACE mar LINK_DEPENDS maz)
>    endif()

Is this also succeptable to the same 

  target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})

effect?

> 
> Other possible names?  Perhaps LINK_PUBLIC and LINK_PRIVATE?
> Perhaps LINK AND LINK_ONLY?

I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which 
are most clear to me. We can change it once we have an implementation to 
talk about.

All the best,

Steve.





More information about the cmake-developers mailing list