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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
