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

[Stephen Kelly]

Brad King wrote:

> 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)

That wouldn't work. I needed this patch:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aca4916b2c124c6ec198c1f88329379458c93727

for this error:

 http://open.cdash.org/testDetails.php?test=173056412&build=2758124

> 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.

Yes, but that is the common case.

> 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. 

Yes.

> We could
> also allow/accept a "-D" in front of definition names and have tcd()
> strip them out when setting the property.

I don't like that idea. It already makes add_definitions complex.

> This would also help in
> cases where variables contain lists meant for the old add_definitions
> command which wants -D.

True, but I think moving away from having a compiler-specific syntax to add 
definitions is a good thing.

> 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?


Thanks,

Steve.