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

[Yves Frederix]

<snip>
> 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.

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.

> 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.

>
>>
>>> 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 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?

Of course the first would provide the solution for my use cases and
the second would be more like a nice-to-have ;)

Regards,
Yves