[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