On 02/08/2013 01:46 PM, Stephen Kelly wrote:
> I noticed that
>
> add_custom_target(check ALL
> COMMAND ${CMAKE_COMMAND} -E echo check
> )
>
> target_link_libraries(check somelib)
>
> works. That should probably be an error, but making it one requires a policy
> and can be deferred.
Yes.
> I also looked into the generator expressions which deal with targets, and
> considered changing TARGET_PROPERTY, LINKED, and TARGET_DEFINED to not
> consider utility targets as targets. TARGET_FILE and friends already errors
> on utility and UNKNOWN_LIBRARY targets.
Hmm...
> I think it might make sense to handle them particularly in LINKED, but I
> notice set_property and set_target_properties also work fine with them
> (should that be changed too?)
The ExternalProject module makes heavy use of properties on custom targets.
It is common. It's just INTERFACE properties that do not make sense.
>, so I don't know if TARGET_PROPERTY should be
> changed too. If it is, then it makes sense to change TARGET_DEFINED to
> consider utilities to not be targets, as that expression is most usefully
> used with TARGET_PROPERTY.
Perhaps TARGET_DEFINED is not a good name then. What are we really
asking? TARGET_LINKABLE?
> Is there a real need to allow things like
>
> add_custom_target(check ALL
> COMMAND ${CMAKE_COMMAND} -E echo $<TARGET_PROPERTY:check,message>
> )
> set_property(TARGET check PROPERTY message Hello)
Yes, I think that makes sense. I can imagine ExternalProject might
find a use for this.
-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
