[CMake] Why does INTERFACE type targets only support whitelisted properties?

[Nils Gladitz]

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