[CMake] 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 <bram at cocamware.com> 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 <bram at cocamware.com> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180702/632137b3/attachment.html>