[cmake-developers] Interface includes and defines plumbing

Stephen Kelly steveire at gmail.com
Wed Jan 16 16:40:37 EST 2013


Brad King wrote:

> On 01/08/2013 09:07 AM, Stephen Kelly wrote:
>> Done now, thanks.
> 
> Currently target_include_directories cannot be used with a RHS target
> that has not yet been created.  This could be problematic for projects
> that want circular include dependencies, especially with targets in
> sibling directories.
> 
> Can the "non-target/relative-path argument" error be moved to generate
> time when $<TARGET_PROPERTY:INTERFACE_INCLUDE_DIRECTORIES,BadTarget>
> is evaluated?  Does this make sense?

It is probably possible. 

Everything in the INCLUDE_DIRECTORIES property should be a relative path if 
added by include_directories(), and also if the property is populated 
directly, given http://www.cmake.org/Bug/view.php?id=13188 .

So cmTarget::GetIncludeDirectories could probably be taught to 
cmGeneratorExpression::Split and treat anything non-relative as a target. A 
policy may be needed for that, as per the above bug report.

A workaround is to fully spell out the generator expressions (I've just 
pushed a fix for this):

 target_link_libraries(foo PRIVATE 
    $<TARGET_PROPERTY:bar_in_sibling_dir,INTERFACE_INCLUDE_DIRECTORIES>)

but this is less convenient and not going in the same declarative direction 
we'd like to.

I notice that tll() allows RHS targets to be not-yet-existing targets. If 
that-or-a-new-command is used instead (which I'd expect to be common), it 
may not be a big problem.

Thanks,

Steve.





More information about the cmake-developers mailing list