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

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Reply via email to