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

Stephen Kelly steveire at gmail.com
Tue Dec 18 11:09:26 EST 2012


Brad King wrote:

> On 12/18/2012 10:38 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> I'll defer my thoughts on details of defining and exporting each
>>> part of the interface for a future message after we've discussed
>>> the overall approach.
>> 
>> I think it would be more helpful to understanding your proposal if you
>> detail those now instead.
>> 
>> So far I don't understand your proposal. I don't see how it could work
>> and satisfy the goals we've been discussing until now.
> 
> I'm not sure when I'll have time to write out all the details, but here
> is a summary of the approach.
> 
> When building a given target users will not necessarily populate the
> LINK_LIBRARIES, INCLUDE_DIRECTORIES, or COMPILE_DEFINITIONS properties
> for the target's dependencies.  Instead users will use the new command
> to populate a USE_INTERFACES property.  

> At generate time that property
> will be used to accumulate values from INTERFACE_-like properties on
> the named interfaces and append them to LINK_LIBRARIES, etc.

You wrote before that you don't propose using properties and generator 
expressions:

> This can all be done inside C++ structures rather than with
> properties and generator expressions because it is only done during
> generation.

That is the kind of thing I'm confused about. I don't see what value the 
USE_INTERFACES property adds.

Here's some code that works with my branch (imagining a new command, and 
without the USE_INTERFACES property). How would it look with your proposal?

 add_library(foo ...)
 set_property(TARGET foo PROPERTY INTERFACE_INCLUDE_DIRECTORIES
   $<$<CONFIG:Debug>:/foo/include>
 )

 add_executable(bar ...)
 target_use_interfaces(bar INTERFACES foo)


The idea of a new command and the idea of a non-granular USE_INTERFACE 
property are not tied together. But if you clarify what you wrote about 
how/when *_INTERFACE properties would be used, that would at least get the 
understanding of your proposal off the ground.

Thanks,

Steve.





More information about the cmake-developers mailing list