|
Notes |
|
|
(0034781)
|
|
Stephen Kelly
|
2013-12-16 06:35
(edited on: 2013-12-16 06:36) |
|
You need to be more specific. Post some code which shows why the property on the INTERFACE library needs to be set, and no alternative is sensible. http://sscce.org/ [^]
|
|
|
|
(0034782)
|
|
Arunmozhi
|
|
2013-12-16 08:00
|
|
User defined properties can be used for any reason to store some target specific information globally. I simply do not see a reason to block it for a specific target type.
If you really looking for a usage requirement, I store the type of some custom targets in a specific property. I assumed that when I query this type property from any target (other than those custom targets), it shall return empty string. But I saw error when I queried the property from a interface_library target and hence raised this bug. There will definitely be alternative way of doing things, but I see this issue more from the theoretical and compatibility point of view rather than practical reasons. The module which I wrote for previous versions of cmake now gives error due to this. This module generates Android.mk for our project, so definitely not for a simple usage of cmake. |
|
|
|
(0034859)
|
|
Stephen Kelly
|
|
2013-12-23 11:17
|
|
> The module which I wrote for previous versions of cmake now gives error due to this.
This is acceptable. The module pre-dates the INTERFACE_LIBRARY type.
Another module might attempt to read the LOCATION of an INTERFACE_LIBRARY target for example, which makes no sense at all.
It just so happens that your module doesn't otherwise trip up on INTERFACE_LIBRARY targets, but it is a new type of object with new semantics and it is reasonable to require new handling for it. |
|
|
|
(0036065)
|
|
Robert Maynard
|
|
2014-06-02 08:37
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
CMakeLists.txt (298) 2013-12-16 02:35