[cmake-developers] Setting include directories via target_link_libraries() ?

Stephen Kelly steveire at gmail.com
Fri Dec 21 19:18:13 EST 2012


Brad King wrote:

> On 12/21/2012 01:08 PM, Stephen Kelly wrote:
>> If the target_use_interfaces command did not manipulate a USE_INTERFACES
>> property, but instead manipulated the mulitple INTERFACE_* properties in-
>> place (not appending) as my branch already does, it would be more clear.
>> 
>> I added a patch to my wip-target-interface branch to illustrate that a
>> bit.
>> 
>> Note that my branch still uses the tll() command for populating the
>> INTERFACE_* properties, but that does not matter as the
>> transitivity-with- properties question is separate to the new-command
>> question.
> 
> Okay, I think the per-property approach may work with the new command.

Yes, I think it would.

> The new command can have my proposed signature but will immediately update
> the individual properties:
> 
>  target_use_interfaces(tgt [<PUBLIC|PRIVATE|INTERFACE> tgts...]...)
> 
> For each t in tgts the command will populate target properties of tgt.
> For example the INCLUDE_DIRECTORIES will be updated as (pseudo-code):
> 
>  includes = "$<TARGET_PROPERTY:t,INTERFACE_INCLUDE_DIRECTORIES>"
>  if PUBLIC or PRIVATE:
>    tgt.INCLUDE_DIRECTORIES.append(includes)
>  if PUBLIC or INTERFACE:
>    tgt.INTERFACE_INCLUDE_DIRECTORIES.append(includes)
> 
> and similar appropriate updates for COMPILE_DEFINTIONS and link libraries.

Yes. And hopefully before merging into master, also COMPILE_OPTIONS and 
LINK_OPTIONS can be handled similarly at least. I think there should be 
enough time for that. 

There are also other dimensions on the wiki page, such as LINK_DIRECTORIES, 
and other possible needs for generator expressions (eg for 
platforms/compilers. The wiki has a link to 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/42060/focus=42095), 
but I don't know enough about that yet. 

There is also the question of being able to check the language in generator 
expressions, which is not yet possible, and may require adding const char 
*lang to a lot more APIs. That was part of earlier discussions we had, but 
has somewhat fallen by the wayside:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3748

> Transitivity will be handled by recursive generator expression evaluation
> in each property.

Only for INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS, so far. The 
LINK_OPTIONS and COMPILE_OPTIONS will probably work the same way.

Transitivity for link libraries will continue to work as it currently does 
(not via recursive generator expression evaluation, as it currently is in my 
branch).

Transitivity for certain features like POSITION_INDEPENDENT_CODE will be 
based on detection from what is in the link closure (as it is currently in 
my branch).

> Basically this is what you have in mind for tll() but with the new
> command, right?

Yes, what you wrote is what I have in mind and in the branch, except that my 
branch uses tll().

I don't think all the information is available from either side of the 
debate on new-command vs use-tll. I'd like to defer the details of the 
porcelain API for now and focus instead on the plumbing API and 
implementation.

I'll try to split up the commits in my branch a bit to put all the porcelain 
use-tll commits at the end, and we can focus on the plumbing commits. 

First I'd like to solidify and finish what's there (eg, I haven't yet 
documented the INTERFACE_INCLUDE_DIRECTORIES property), get it reviewed, 
then add COMPILE_OPTIONS and LINK_OPTIONS and their INTERFACE variants, then 
add new generator expressions such as $<LANGUAGE:lang>. 

After that I'd like to return to the questions around the porcelain API. 

What do you think of that?

Thanks,

Steve.





More information about the cmake-developers mailing list