[cmake-developers] target_include_directories() accepts only absolute paths ?

Brad King brad.king at kitware.com
Mon Jan 28 14:30:38 EST 2013


On 01/28/2013 12:27 PM, Stephen Kelly wrote:
>>> Yes. However code like this would be ambiguous until generate-time:
>>>
>>>  target_include_directories(foo PRIVATE bar)
>>>
>>> Is bar a target or a directory? That means storing a longer string for
>>> bar:
>>
>> Simply saying that an existing directory with the given name has priority
>> over a target with the same name would not be ok ?
> 
> Currently we do the opposite. First check if 'bar' is a target name, and if 
> not, then treat it as a directory.

Can we consider using syntax to make this unambiguous?

For non-targets we can require at least one slash to subsume full paths
and allow relative paths:

 target_include_directories(foo PRIVATE bar/ ./zot)

Perhaps the existence of a non-slash subdirectory could also be enough
for a non-target.

> There is the disadvantage that the case of
>  target_compile_definitions(foo PRIVATE SOME_DEFINE)
> now expands in the COMPILE_DEFINITIONS property to
>  "$<$<TARGET_DEFINED:SOME_DEFINE>:$<TARGET_PROPERTY:SOME_DEFINE,INTERFACE_COMPILE_DEFINITIONS>;$<$<NOT:$<TARGET_DEFINED:SOME_DEFINE>>:SOME_DEFINE>"

If SOME_DEFINE is *already* a target then this is not needed.
Only out-of-order cases need it.  Also we should be able to perform
partial evaluation at generate time so that the exported interface
does not have this.  Users could also write

 target_compile_definitions(foo PRIVATE bar=)

to state that 'bar' is a definition name and not a target.  We could
also allow/accept a "-D" in front of definition names and have tcd()
strip them out when setting the property.  This would also help in
cases where variables contain lists meant for the old add_definitions
command which wants -D.

What's missing is a concise syntax to say that a string *is* a target.
One could write

 $<TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS>

but that exposes the plumbing.  Ideas?

-Brad


More information about the cmake-developers mailing list