[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