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

[Nils Gladitz]

On 01/08/2016 01:07 PM, Yves Frederix wrote:
>> It might help the discussion if you could elaborate what use cases you have
>> in mind for non-whitelisted properties.
> I deliberately did not mention my particular use case from the start
> simply because I am interested in the reasoning behind the limitation,
> not directly in how I can work around a particular instance ;)
> However, since you asked, in this case I was trying to access the
> SOURCE_DIR property of an INTERFACE target. This property is in fact
> defined on the target, but I cannot access it due to the whitelisting
> being enforced by get_property.

Still at the very least this might be an argument to whitelist SOURCE_DIR.

An argument for the whitelist diagnostics might be that it reduces 
reports from users which try to set build properties that do not have 
any effect in context of interface targets.
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).

>
>> Assuming you mean the recent discussion on the FOLDER property:
>>    The FOLDER property would have no effect on interface targets even if the
>> property were whitelisted.
>>    Interface targets don't have project files so there is nothing to be
>> sorted into a folder either.
> This was indeed the discussion I was referring to. One could discuss
> whether or not interface targets should have project files and/or
> source files associated to them (as one would expect of a header-only
> library), but I am trying not to go there at this point. Being able to
> get/set any property without CMake exiting with an error could be seen
> independent of this I think.

I would also see this as an independent issue.
If there were projects and sources for interface targets that would be 
an argument to whitelist e.g. FOLDER not an argument to allow all 
properties.

>
>> As for whitelisting vs blacklisting:
>>    The whitelist is significantly shorter and easier to maintain (when new
>> properties are added) than an equivalent blacklist.
> I cannot really judge this statement (what properties should really
> need to be blacklisted? All standard CMake target properties?)

To start with all CMake target properties that aren't currently on the 
whitelist.


> In any case, if blacklisting were used, it would allow a developer to
> assign custom target properties (for the sake of argument, let's
> assume that in some more complex projects one could make good use of
> them) without having to give this custom property a name that starts
> with INTERFACE_.

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 don't think anything should be changed however unless there are actual 
use cases that aren't supported by the current implementation.

Nils