On 01/08/2016 02:50 PM, Yves Frederix wrote:
You are explicitly mentioning 'setting' of a property. IMHO there is a
big difference between setting and getting a property. If
white/blacklisting is enforced during setting only, wouldn't this be
sufficient? This would make it possible to simply access all
properties that are automatically assigned to the target (which I
assume implies that by definition they should make sense?). A
non-acceptable property could not have been set and would hence not be
found, making it possible to check for its existence in the "standard"
way.
The same argument might hold for getting of properties.
E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties
now but was implemented in the future.
A user might e.g. think that a specific property should work because CMake
did not issue any diagnostics and open an issue.
The diagnostic implies that this behavior is by design.
It also prevents users from using existing properties which currently don't
have semantics for INTERFACE targets but might be implemented in the future
(potentially with different semantics than expected by the user).
Ok, this somehow contradicts my above assumption and is somewhat
surprising. Wouldn't it make sense to simply not set these properties
in the first place if they have incorrect semantics? This way,
get_property would not need to care about them and it would anyhow not
stop their correct implementation in the future.
I meant existing as in defined for regular build targets not as in
actually set for interface targets.
get_property() would return an empty string for those if they weren't
whitelisted and one might argue that this could suffice.
On the other hand users often assume that they get a valid value and
don't actually check.
I think allowing custom (non cmake defined) properties might be a valid
argument.
These could perhaps also be supported through e.g. user extension of the
whitelist.
I like this idea. With this in place, one would not need to wait for a
new CMake release if a valid property were missing from the whitelist
or if one wanted to use custom properties.
I don't think anything should be changed however unless there are actual use
cases that aren't supported by the current implementation.
Does this mean that you would have doubts about patches that:
- provide a way for the user to extend the whitelist?
- remove the need for whitelisting in get_property by making CMake
only automatically assign sensible target properties?
The issue is less that CMake assigns these properties (I don't know of
any such case but I haven't checked) and more that users might just
expect them to be set (which does not provide a diagnostic).
Personally I would not object to either approach as long as there are
actual use cases.
Without use cases such changes would be by definition useless.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
