<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz <span dir="ltr"><<a href="mailto:nilsgladitz@gmail.com" target="_blank">nilsgladitz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 01/08/2016 02:50 PM, Yves Frederix wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You are explicitly mentioning 'setting' of a property. IMHO there is a<br>
big difference between setting and getting a property. If<br>
white/blacklisting is enforced during setting only, wouldn't this be<br>
sufficient? This would make it possible to simply access all<br>
properties that are automatically assigned to the target (which I<br>
assume implies that by definition they should make sense?). A<br>
non-acceptable property could not have been set and would hence not be<br>
found, making it possible to check for its existence in the "standard"<br>
way.<br>
</blockquote>
<br></span>
The same argument might hold for getting of properties.<br>
E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties now but was implemented in the future.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A user might e.g. think that a specific property should work because CMake<br>
did not issue any diagnostics and open an issue.<br>
The diagnostic implies that this behavior is by design.<br>
<br>
It also prevents users from using existing properties which currently don't<br>
have semantics for INTERFACE targets but might be implemented in the future<br>
(potentially with different semantics than expected by the user).<br>
</blockquote>
Ok, this somehow contradicts my above assumption and is somewhat<br>
surprising. Wouldn't it make sense to simply not set these properties<br>
in the first place if they have incorrect semantics? This way,<br>
get_property would not need to care about them and it would anyhow not<br>
stop their correct implementation in the future.<br>
</blockquote>
<br></span>
I meant existing as in defined for regular build targets not as in actually set for interface targets.<br>
get_property() would return an empty string for those if they weren't whitelisted and one might argue that this could suffice.<br>
On the other hand users often assume that they get a valid value and don't actually check.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think allowing custom (non cmake defined) properties might be a valid<br>
argument.<br>
These could perhaps also be supported through e.g. user extension of the<br>
whitelist.<br>
</blockquote>
I like this idea. With this in place, one would not need to wait for a<br>
new CMake release if a valid property were missing from the whitelist<br>
or if one wanted to use custom properties.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I don't think anything should be changed however unless there are actual use<br>
cases that aren't supported by the current implementation.<br>
</blockquote>
Does this mean that you would have doubts about patches that:<br>
  - provide a way for the user to extend the whitelist?<br>
  - remove the need for whitelisting in get_property by making CMake<br>
only automatically assign sensible target properties?<br>
</blockquote>
<br></span>
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).<br>
<br>
Personally I would not object to either approach as long as there are actual use cases.<br>
Without use cases such changes would be by definition useless.</blockquote><div><br></div>I have another INTERFACE property use case that is not whitelisted, but should be: VERSION<div><br></div><div>Consider library project Foo that uses a header-only project Bar. In FooConfig.cmake, it is a important to ensure any projects using Foo also use the exact same version of Bar that Foo was originally built with (Failure to do so can lead to subtle, hard-to-find bugs like violation of the one definition rule). Assuming project Bar creates an imported target "Bar" with a VERSION property set like:</div><div><br></div><div>  set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)</div><div><br></div><div>Then project Foo should be able to have something like:</div><div><br></div><div>== CMakeLists.txt ==</div><div>...</div><div><div>get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)</div><div>configure_file(<a href="http://FooConfig.cmake.in">FooConfig.cmake.in</a> FooConfig.cmake @ONLY)</div></div><div><br></div><div>== <a href="http://FooConfig.cmake.in">FooConfig.cmake.in</a> ==</div><div>...</div><div>find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)</div><div><br></div><div>But, alas, this is not currently possible. I'm ambivalent about whether INTERFACE properties should be whitelisted vs blacklisted vs unrestricted, but at least this VERSION property seems valid to allow.</div><div><br></div><div>Taylor</div></div></div></div>