Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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 attachment: loose.vcf-- 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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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. attachment: loose.vcf-- 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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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. attachment: loose.vcf-- 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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
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
[CMake] How to deal with incompatible changes in interface of target_link_libraries()?
-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
