How to deal with incompatible changes in interface of target_link_libraries()?

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

How to deal with incompatible changes in interface of target_link_libraries()?

Marcel Loose-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'm struggling with the problem that CMake 2.8.12 introduced
incompatible changes in the interface of target_link_libraries()
w.r.t. dealing with direct and indirect (transitive) link
dependencies. Pre-2.8.12 you would use the keyword
LINK_INTERFACE_LIBRARIES to indicate indirect link dependencies. CMake
2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
triggering policy warnings CMP0022 and CMP0023.

What is the proper way to get rid of these policy warnings, while at
the same time staying backward compatible with older CMake versions? I
need to support all 2.8.x versions, but I don't want to set these
policies to OLD. I also don't want to wrap each call to
target_link_libraries() inside a conditional

        if (${CMAKE_VERSION} VERSION_LESS 2.8.12)
        ...
        else()
        ...
        endif()

Of course I could put this logic in a macro, but how then do I handle
the new keywords. Some hints or tips would be very much appreciated.

Kind regards,
Marcel Loose.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT5iYxAAoJEEpMyb1AIWdYFR4IAJXH0KV9dc8cCPItf2R1UTTS
dkdvoqJtRRqKIS/fyQv4VHsbqP0DqH9qlCjc6O6h27I461PUwwfk+hYNDQI+q5wH
SKu3kosT4rIxDg+CmGr/yhzSdzuWKyhRu+L4syunoOxeXXreKSzSIrTvdRA1fPZg
aSJR4hvnA5cDUA/0pdV9pPKm4JATK8s2/S64PPjA2CRbq6pZfnnX4tRrQMnkt/+S
R1xmmVVzcuctdIAdanUnDlTfRHMNOyY3uWozXkO2OCeTFJLc00xQcvJdcr2zXyRx
EtvpFVmBU9IsAu4LY3gZZfjWwpwsMyYptaYSSF7oDJjshw5LctObJZ89jgFhtmw=
=RhRJ
-----END PGP SIGNATURE-----
--

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: How to deal with incompatible changes in interface of target_link_libraries()?

Brad King
On 08/09/2014 09:46 AM, Marcel Loose wrote:
> CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
> immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
> triggering policy warnings CMP0022 and CMP0023.
>
> What is the proper way to get rid of these policy warnings, while at
> the same time staying backward compatible with older CMake versions?

From the documentation of CMP0022:

 "Warning-free future-compatible code which works with CMake 2.8.9
  onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC
  keywords of target_link_libraries()."

Actually it should say 2.8.7, not 2.8.9.  CMP0023 docs mention 2.8.7.

-Brad
--

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: How to deal with incompatible changes in interface of target_link_libraries()?

Marcel Loose

On 11/08/14 18:47, Brad King wrote:

> On 08/09/2014 09:46 AM, Marcel Loose wrote:
>> CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
>> immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
>> triggering policy warnings CMP0022 and CMP0023.
>>
>> What is the proper way to get rid of these policy warnings, while at
>> the same time staying backward compatible with older CMake versions?
> From the documentation of CMP0022:
>
>  "Warning-free future-compatible code which works with CMake 2.8.9
>   onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC
>   keywords of target_link_libraries()."
>
> Actually it should say 2.8.7, not 2.8.9.  CMP0023 docs mention 2.8.7.
>
> -Brad
Hmm,

That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention
LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read
the following in the docs on target_link_libraries

       The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify
both the
       link dependencies and the link interface in one command.  This
       signature is for compatibility only.  Prefer the PUBLIC or PRIVATE
       keywords instead.

"... for compatibility only" didn't give me the feeling that this is the
way to go, which is underscored by the next sentence: "Prefer the ..."

On a side note. Even using the new PRIVATE and PUBLIC keywords I am
unable to exactly specify which libraries are needed for linking.
Without breaking builds with static libraries, I am forced to specify
too many library dependencies. Maybe I'm doing something wrong, but my
setup is quite complicated. Fortunately, modern version of ld will get
rid of unused libraries anyway, so it's not really that much of an issue
for me.

Regards,
Marcel Loose.

--

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

loose.vcf (304 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with incompatible changes in interface of target_link_libraries()?

Marcel Loose
In reply to this post by Brad King

On 11/08/14 18:47, Brad King wrote:

> On 08/09/2014 09:46 AM, Marcel Loose wrote:
>> CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
>> immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
>> triggering policy warnings CMP0022 and CMP0023.
>>
>> What is the proper way to get rid of these policy warnings, while at
>> the same time staying backward compatible with older CMake versions?
> From the documentation of CMP0022:
>
>  "Warning-free future-compatible code which works with CMake 2.8.9
>   onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC
>   keywords of target_link_libraries()."
>
> Actually it should say 2.8.7, not 2.8.9.  CMP0023 docs mention 2.8.7.
>
> -Brad
Hi,

Another problem I faced with policy CMP0022 is that I was unable to
really silence it. Setting the policy to OLD doesn't really work (at
least not in my case), maybe because the "cmake_policy()" command is
scoped(?). I have a macro that contains the now deprecated use of
LINK_INTERFACE_LIBRARIES, so I thought I could simply wrap that
statement inside the following code block:

    if (POLICY CMP0022)
        cmake_policy(PUSH)
        cmake_policy(SET CMP0022 OLD)
    endif()
    target_link_libraries (... LINK_INTERFACE_LIBRARIES ...)
    if (POLICY CMP0022)
        cmake_policy(POP)
    endif()

But that doesn't seem to work. I still get the policy warnings for
CMP0022. Also setting the policy to OLD once at top-level doesn't seem
to work; probably due to policy scoping. I played a bit with
NO_POLICY_SCOPE to different include() and find_package() statements,
but to no avail.

Regards,
Marcel Loose.



--

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

loose.vcf (304 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with incompatible changes in interface of target_link_libraries()?

Brad King
On 08/12/2014 03:59 AM, Marcel Loose wrote:
> Another problem I faced with policy CMP0022 is that I was unable to
> really silence it. Setting the policy to OLD doesn't really work (at
> least not in my case), maybe because the "cmake_policy()" command is
> scoped(?).

For CMP0022 and CMP0023 the policy setting is recorded on each target
when it is created by and add_library command.  That affects all
target_link_libraries calls that give the library as the first argument.

> setting the policy to OLD once at top-level doesn't seem to work

Any call to cmake_minimum_required(VERSION) will unset policies
introduced in versions larger than that named.

FYI, the only intended use case for setting a policy to OLD is to
quiet warnings in a maintenance branch of an existing release.
Some day support for OLD behavior of some policies may be dropped,
so all project development moving forward should set the policy
to NEW.

-Brad

--

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: How to deal with incompatible changes in interface of target_link_libraries()?

Brad King
In reply to this post by Marcel Loose
On 08/12/2014 03:48 AM, Marcel Loose wrote:

> That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention
> LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read
> the following in the docs on target_link_libraries
>
>        The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify
> both the
>        link dependencies and the link interface in one command.  This
>        signature is for compatibility only.  Prefer the PUBLIC or PRIVATE
>        keywords instead.
>
> "... for compatibility only" didn't give me the feeling that this is the
> way to go, which is underscored by the next sentence: "Prefer the ..."

If your project requires CMake 2.8.12 or higher then it is preferred to
use PUBLIC/PRIVATE.  For compatibility with earlier CMake versions you
can still use LINK_PUBLIC/LINK_PRIVATE.

> On a side note. Even using the new PRIVATE and PUBLIC keywords I am
> unable to exactly specify which libraries are needed for linking.

Can you provide a concrete example of this trouble?

-Brad

--

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: How to deal with incompatible changes in interface of target_link_libraries()?

Marcel Loose-2
Op 12-08-14 om 15:06 schreef Brad King:
> On 08/12/2014 03:48 AM, Marcel Loose wrote:
>> On a side note. Even using the new PRIVATE and PUBLIC keywords I am
>> unable to exactly specify which libraries are needed for linking.
>
> Can you provide a concrete example of this trouble?
I've further analyzed the problem, and figured out that the troubles I'm
facing are caused by the way I add libraries and executables to the
build. It's no big deal. Like I said, modern versions of ld will get rid
of unused libraries anyway, so the only remaining problem would be some
increased link time. I can live with that.
>
> -Brad
>
Cheers,
Marcel.

--

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: How to deal with incompatible changes in interface of target_link_libraries()?

Alexander Neundorf-3
In reply to this post by Brad King
On Tuesday, August 12, 2014 09:06:13 Brad King wrote:
...
> FYI, the only intended use case for setting a policy to OLD is to
> quiet warnings in a maintenance branch of an existing release.
> Some day support for OLD behavior of some policies may be dropped,
> so all project development moving forward should set the policy
> to NEW.

Fixing a warning may make the project require the newer cmake version.
E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0,
which generates a warning, a developer using cmake 3.0.0 may see the warning
and fix it, but by that he may have broken the build for the required 2.8.10
and actually now 3.0.0 is required.

Alex
--

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: How to deal with incompatible changes in interface of target_link_libraries()?

Marcel Loose

On 20/08/14 22:50, Alexander Neundorf wrote:

> On Tuesday, August 12, 2014 09:06:13 Brad King wrote:
> ...
>> FYI, the only intended use case for setting a policy to OLD is to
>> quiet warnings in a maintenance branch of an existing release.
>> Some day support for OLD behavior of some policies may be dropped,
>> so all project development moving forward should set the policy
>> to NEW.
> Fixing a warning may make the project require the newer cmake version.
> E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0,
> which generates a warning, a developer using cmake 3.0.0 may see the warning
> and fix it, but by that he may have broken the build for the required 2.8.10
> and actually now 3.0.0 is required.
>
> Alex
That's exactly the problem I keep running into. I want my project to be
compatible with any CMake 2.8.x, but also want it to run warning-free
with newer CMake versions, without having to resort to -Wno-dev. AFAIK
that can only be accomplished by setting some policies temporarily to
OLD. However, wrapping target_link_libraries() in a macro that
temporarily sets CMP0022 to OLD failed, due to scoping issues :(

Cheers,
Marcel

--

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

loose.vcf (304 bytes) Download Attachment