how to deprecate a target?

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

how to deprecate a target?

Bram de Greve
Hi all,

Consider this situation.  I'm building a Foo packaged, to be used by a
Bar project.

Foo used to export its target as simply foo.
Now it exports its target as Foo::foo.

Bar contains this:
add_library(bar ...)
target_link_libraries(bar foo)

This of course must now be:
add_library(bar ...)
target_link_libraries(bar Foo::foo)

But if bar still links to the foo instead of Foo::foo, then CMake
doesn't really complain.  foo doesn't exist, but configures and
generates just fine.  Of course, you'll face strange build errors, from
which it isn't immediately apparent what's causing this ...

How can I make sure CMake will complain loudly when bar still links to foo?

Thanks,
Bram.

--

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

Re: how to deprecate a target?

Robert Maynard
I am not aware of a nice way to setup CMake to error out if a user
links to `foo` instead of `Foo::foo`.
On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <[hidden email]> wrote:

>
> Hi all,
>
> Consider this situation.  I'm building a Foo packaged, to be used by a
> Bar project.
>
> Foo used to export its target as simply foo.
> Now it exports its target as Foo::foo.
>
> Bar contains this:
> add_library(bar ...)
> target_link_libraries(bar foo)
>
> This of course must now be:
> add_library(bar ...)
> target_link_libraries(bar Foo::foo)
>
> But if bar still links to the foo instead of Foo::foo, then CMake
> doesn't really complain.  foo doesn't exist, but configures and
> generates just fine.  Of course, you'll face strange build errors, from
> which it isn't immediately apparent what's causing this ...
>
> How can I make sure CMake will complain loudly when bar still links to foo?
>
> Thanks,
> Bram.
>
> --
>
> 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
--

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

Re: how to deprecate a target?

Bram de Greve
That is unfortunate ... do you know any not-so-nice ways?

So, what would you recommend here?

I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES
and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do
that nicely with variable watches.

But what about the target names?  If I want to guarantee a seamless
transition period, I should opt to keep using the "foo" target names. 
But then there's no way to "upgrade" to "Foo::foo" targets without
breakage, since there's no deprecation strategy. And I can't use target
aliases, since that is not allowed on imported targets.

To answer my own question, I think the best thing is to move to the
"Foo::foo" targets right now.  There's at least one downstream package
that will be hurt by this, but the damage is less than waiting for
everyone to have moved to the "foo" target first.

Best,

Bram.


On 6/29/2018 20:22, Robert Maynard wrote:

> I am not aware of a nice way to setup CMake to error out if a user
> links to `foo` instead of `Foo::foo`.
> On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <[hidden email]> wrote:
>> Hi all,
>>
>> Consider this situation.  I'm building a Foo packaged, to be used by a
>> Bar project.
>>
>> Foo used to export its target as simply foo.
>> Now it exports its target as Foo::foo.
>>
>> Bar contains this:
>> add_library(bar ...)
>> target_link_libraries(bar foo)
>>
>> This of course must now be:
>> add_library(bar ...)
>> target_link_libraries(bar Foo::foo)
>>
>> But if bar still links to the foo instead of Foo::foo, then CMake
>> doesn't really complain.  foo doesn't exist, but configures and
>> generates just fine.  Of course, you'll face strange build errors, from
>> which it isn't immediately apparent what's causing this ...
>>
>> How can I make sure CMake will complain loudly when bar still links to foo?
>>
>> Thanks,
>> Bram.
>>
>> --
>>
>> 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

--

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

Re: how to deprecate a target?

Petr Kmoch
Hi Bram.

Wild idea: could you also define a non-namespaced target `foo` and craft it such that linking against it generates a linker warning? Something like "Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined twice, ignoring weak definition."

Petr

On 2 July 2018 at 00:11, Bram de Greve <[hidden email]> wrote:
That is unfortunate ... do you know any not-so-nice ways?

So, what would you recommend here?

I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that nicely with variable watches.

But what about the target names?  If I want to guarantee a seamless transition period, I should opt to keep using the "foo" target names.  But then there's no way to "upgrade" to "Foo::foo" targets without breakage, since there's no deprecation strategy. And I can't use target aliases, since that is not allowed on imported targets.

To answer my own question, I think the best thing is to move to the "Foo::foo" targets right now.  There's at least one downstream package that will be hurt by this, but the damage is less than waiting for everyone to have moved to the "foo" target first.

Best,

Bram.



On 6/29/2018 20:22, Robert Maynard wrote:
I am not aware of a nice way to setup CMake to error out if a user
links to `foo` instead of `Foo::foo`.
On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <[hidden email]> wrote:
Hi all,

Consider this situation.  I'm building a Foo packaged, to be used by a
Bar project.

Foo used to export its target as simply foo.
Now it exports its target as Foo::foo.

Bar contains this:
add_library(bar ...)
target_link_libraries(bar foo)

This of course must now be:
add_library(bar ...)
target_link_libraries(bar Foo::foo)

But if bar still links to the foo instead of Foo::foo, then CMake
doesn't really complain.  foo doesn't exist, but configures and
generates just fine.  Of course, you'll face strange build errors, from
which it isn't immediately apparent what's causing this ...

How can I make sure CMake will complain loudly when bar still links to foo?

Thanks,
Bram.

--

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

--

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


--

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

Re: how to deprecate a target?

Marc CHEVRIER
FYI: Starting with CMake 3.11, it is now possible to define an alias of an imported target.

Le lun. 2 juil. 2018 à 09:27, Petr Kmoch <[hidden email]> a écrit :
Hi Bram.

Wild idea: could you also define a non-namespaced target `foo` and craft it such that linking against it generates a linker warning? Something like "Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined twice, ignoring weak definition."

Petr

On 2 July 2018 at 00:11, Bram de Greve <[hidden email]> wrote:
That is unfortunate ... do you know any not-so-nice ways?

So, what would you recommend here?

I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that nicely with variable watches.

But what about the target names?  If I want to guarantee a seamless transition period, I should opt to keep using the "foo" target names.  But then there's no way to "upgrade" to "Foo::foo" targets without breakage, since there's no deprecation strategy. And I can't use target aliases, since that is not allowed on imported targets.

To answer my own question, I think the best thing is to move to the "Foo::foo" targets right now.  There's at least one downstream package that will be hurt by this, but the damage is less than waiting for everyone to have moved to the "foo" target first.

Best,

Bram.



On 6/29/2018 20:22, Robert Maynard wrote:
I am not aware of a nice way to setup CMake to error out if a user
links to `foo` instead of `Foo::foo`.
On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <[hidden email]> wrote:
Hi all,

Consider this situation.  I'm building a Foo packaged, to be used by a
Bar project.

Foo used to export its target as simply foo.
Now it exports its target as Foo::foo.

Bar contains this:
add_library(bar ...)
target_link_libraries(bar foo)

This of course must now be:
add_library(bar ...)
target_link_libraries(bar Foo::foo)

But if bar still links to the foo instead of Foo::foo, then CMake
doesn't really complain.  foo doesn't exist, but configures and
generates just fine.  Of course, you'll face strange build errors, from
which it isn't immediately apparent what's causing this ...

How can I make sure CMake will complain loudly when bar still links to foo?

Thanks,
Bram.

--

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

--

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

--

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

--

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

Re: how to deprecate a target?

Bram de Greve
Hi Petr, Marc,

I guess I could generate a linker warning, it's indeed not-so-nice, but might do the trick ...

It seems aliases are only possible on global imported targets. Mine aren't (which is by default I guess). It's probably not a great idea to make them global ...

Thanks for the suggestions!
Bram

On 7/2/2018 10:20, Marc CHEVRIER wrote:
FYI: Starting with CMake 3.11, it is now possible to define an alias of an imported target.

Le lun. 2 juil. 2018 à 09:27, Petr Kmoch <[hidden email]> a écrit :
Hi Bram.

Wild idea: could you also define a non-namespaced target `foo` and craft it such that linking against it generates a linker warning? Something like "Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined twice, ignoring weak definition."

Petr

On 2 July 2018 at 00:11, Bram de Greve <[hidden email]> wrote:
That is unfortunate ... do you know any not-so-nice ways?

So, what would you recommend here?

I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that nicely with variable watches.

But what about the target names?  If I want to guarantee a seamless transition period, I should opt to keep using the "foo" target names.  But then there's no way to "upgrade" to "Foo::foo" targets without breakage, since there's no deprecation strategy. And I can't use target aliases, since that is not allowed on imported targets.

To answer my own question, I think the best thing is to move to the "Foo::foo" targets right now.  There's at least one downstream package that will be hurt by this, but the damage is less than waiting for everyone to have moved to the "foo" target first.

Best,

Bram.



On 6/29/2018 20:22, Robert Maynard wrote:
I am not aware of a nice way to setup CMake to error out if a user
links to `foo` instead of `Foo::foo`.
On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve <[hidden email]> wrote:
Hi all,

Consider this situation.  I'm building a Foo packaged, to be used by a
Bar project.

Foo used to export its target as simply foo.
Now it exports its target as Foo::foo.

Bar contains this:
add_library(bar ...)
target_link_libraries(bar foo)

This of course must now be:
add_library(bar ...)
target_link_libraries(bar Foo::foo)

But if bar still links to the foo instead of Foo::foo, then CMake
doesn't really complain.  foo doesn't exist, but configures and
generates just fine.  Of course, you'll face strange build errors, from
which it isn't immediately apparent what's causing this ...

How can I make sure CMake will complain loudly when bar still links to foo?

Thanks,
Bram.

--

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

--

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

--

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


--

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