On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz <nilsglad...@gmail.com> wrote:
> > > 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. I have another INTERFACE property use case that is not whitelisted, but should be: VERSION Consider library project Foo that uses a header-only project Bar. In FooConfig.cmake, it is a important to ensure any projects using Foo also use the exact same version of Bar that Foo was originally built with (Failure to do so can lead to subtle, hard-to-find bugs like violation of the one definition rule). Assuming project Bar creates an imported target "Bar" with a VERSION property set like: set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3) Then project Foo should be able to have something like: == CMakeLists.txt == ... get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION) configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY) == FooConfig.cmake.in == ... find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED) But, alas, this is not currently possible. I'm ambivalent about whether INTERFACE properties should be whitelisted vs blacklisted vs unrestricted, but at least this VERSION property seems valid to allow. Taylor
-- 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
