Why does INTERFACE type targets only support whitelisted properties?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does INTERFACE type targets only support whitelisted properties?

Yves Frederix
Hi all,

Motivated by my own struggles with targets of type INTERFACE and a
recent post on this list, I was wondering what is the rationale behind
allowing only a whitelisted set of properties on targets of this type.
I understand that one of the use cases for INTERFACE libraries is to
have a way to work with header-only libraries in a more or less
standard way. Yes, the current implementation is far from optimal on
more than one aspect, but I never understood the reason for the
whitelisting (also google didn't make me any wiser). What am I
missing? Wouldn't INTERFACE targets be easier to use without these
restrictions (or alternatively by switching to blacklisting of some
properties to protect a user from having wrong expectations)?

Thanks!
Yves
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Nils Gladitz-2
On 01/08/2016 11:22 AM, Yves Frederix wrote:

> Hi all,
>
> Motivated by my own struggles with targets of type INTERFACE and a
> recent post on this list, I was wondering what is the rationale behind
> allowing only a whitelisted set of properties on targets of this type.
> I understand that one of the use cases for INTERFACE libraries is to
> have a way to work with header-only libraries in a more or less
> standard way. Yes, the current implementation is far from optimal on
> more than one aspect, but I never understood the reason for the
> whitelisting (also google didn't make me any wiser). What am I
> missing? Wouldn't INTERFACE targets be easier to use without these
> restrictions (or alternatively by switching to blacklisting of some
> properties to protect a user from having wrong expectations)?

It might help the discussion if you could elaborate what use cases you
have in mind for non-whitelisted properties.

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.

As for whitelisting vs blacklisting:
   The whitelist is significantly shorter and easier to maintain (when
new properties are added) than an equivalent blacklist.

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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Yves Frederix
> 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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Nils Gladitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Nils Gladitz-2


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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Taylor Braun-Jones
On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz <[hidden email]> 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)

...
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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Stephen Kelly-2
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,

Steve.


--

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
Reply | Threaded
Open this post in threaded view
|

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

Ben Boeckel-2
In reply to this post by Taylor Braun-Jones
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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Taylor Braun-Jones
In reply to this post by Stephen Kelly-2
On Mon, Jan 11, 2016 at 5:16 PM, Stephen Kelly <steveire@gmaicom> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why does INTERFACE type targets only support whitelisted properties?

Innokentiy Alaytsev
In reply to this post by Yves Frederix
Yves Frederix wrote

> Hi all,
>
> Motivated by my own struggles with targets of type INTERFACE and a
> recent post on this list, I was wondering what is the rationale behind
> allowing only a whitelisted set of properties on targets of this type.
> I understand that one of the use cases for INTERFACE libraries is to
> have a way to work with header-only libraries in a more or less
> standard way. Yes, the current implementation is far from optimal on
> more than one aspect, but I never understood the reason for the
> whitelisting (also google didn't make me any wiser). What am I
> missing? Wouldn't INTERFACE targets be easier to use without these
> restrictions (or alternatively by switching to blacklisting of some
> properties to protect a user from having wrong expectations)?
>
> Thanks!
> Yves


Hello!

Sorry for necroposting.

I had a problem with the same limitations for the INTERFACE_LIBRARY targets'
properties. However, there is an interesting feature of this type of
targets: according to the  documentation
<https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries>
, properties matching INTERFACE_* are allowed to be set. I don't know
whether it is a bug or a feature, but this works not only for standard CMake
target properties but for user-defined properties as well.

Best regards
Innokentiy Alaytsev




--
Sent from: http://cmake.3232098.n2.nabble.com/
--

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:
https://cmake.org/mailman/listinfo/cmake