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

Yves Frederix yves.frederix+cmake at gmail.com
Fri Jan 8 07:07:18 EST 2016


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

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

>
> 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?)
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_.


Yves


More information about the CMake mailing list