Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Taylor Braun-Jones]

On Mon, Jan 11, 2016 at 5:16 PM, Stephen Kelly  wrote:
> Taylor Braun-Jones wrote:
>
>> 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
>
> COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use
> case.
>
> You would populate an INTERFACE_ property on the INTERFACE target, which is
> whitelisted already:
>
>  
> https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties
>
>  http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813

Thanks - that's exactly what I was looking for!

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

Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Ben Boeckel]

On Mon, Jan 11, 2016 at 16:47:03 -0500, Taylor Braun-Jones wrote:
> I have another INTERFACE property use case that is not whitelisted, but
> should be: VERSION

VERSION is a special property for libraries. Particularly the name for
the file with the actual content of the library (the SOVERSION and name
of the library being symlinks to it):

https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html

INTERFACE targets have no need for this property.

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

Also, this property is not a list (probably?), so APPEND isn't really
correct. It indicates that the value here should be (list-)appended to
the existing value.

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

find_package(Foo) should set a Foo_VERSION variable (if known):


https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-version-file

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

Currently, they are whitelisted, but I think any property not understood
by CMake directly (i.e., user-set properties) would probably be fine.

--Ben
-- 

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

Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Taylor Braun-Jones]

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz  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-developers