Re: [cmake-developers] RfD: deprecate link_directories() and link_libraries()
On Tue, Aug 21, 2018 at 09:14:37 +0200, Gregor Jasny via cmake-developers wrote: > How would one deal with '#pragma comment lib' w/o link_directories()? I usually disable it with `-DBOOST_ALL_NO_LIB` (for Boost). In addition, I find them to be not useful because Boost library names change between static and shared (so they can live beside each other) and if you don't set the preprocessor definitions right, they're not going to even use the right filename anyways. Easier to just turn off autolinking and have CMake do the right thing. --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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] RfD: deprecate link_directories() and link_libraries()
Hello, On 20.08.18 19:10, Brad King wrote: On 08/15/2018 01:30 PM, Rolf Eike Beer wrote: My dislike against these functions is probably known, and now I would like to bring this to a new level: I would like to formally deprecate these functions. I don't think they serve any useful purpose anymore, given that now even the pkg-config module can (and does) return absolute paths to the libraries. What harm does their presence cause? Please ask on the user list to see if people are using them. I suspect they may be used by some projects to link to special runtime libraries when cross-compiling. We'd need to make sure there is a better way for all such use cases before deprecating the commands. We use link_directories() on Windows to give the windows linker the path to the boost libraries. Those use '#pragma comment lib' to link required libs. How would one deal with '#pragma comment lib' w/o link_directories()? Thanks, Gregor -- 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-developers
Re: [cmake-developers] RfD: deprecate link_directories() and link_libraries()
Am Montag, 20. August 2018, 19:10:57 CEST schrieb Brad King: > On 08/15/2018 01:30 PM, Rolf Eike Beer wrote: > > My dislike against these functions is probably known, and now I would like > > to bring this to a new level: I would like to formally deprecate these > > functions. I don't think they serve any useful purpose anymore, given > > that now even the pkg-config module can (and does) return absolute paths > > to the libraries. > What harm does their presence cause? > > Please ask on the user list to see if people are using them. > > I suspect they may be used by some projects to link to special runtime > libraries when cross-compiling. We'd need to make sure there is a > better way for all such use cases before deprecating the commands. I have only seen this commands in failed attempts to convert Makefiles to CMake without using the proper methods of calling find_library(). And then showing up here or in #cmake and complaining that it breaks. So, has anyone an example where these are still needed with CMake 3.12 for anything that _can't_ be done properly? Eike signature.asc Description: This is a digitally signed message part. -- 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-developers
Re: [cmake-developers] RfD: deprecate link_directories() and link_libraries()
On 08/15/2018 01:30 PM, Rolf Eike Beer wrote: > My dislike against these functions is probably known, and now I would like to > bring this to a new level: I would like to formally deprecate these > functions. > I don't think they serve any useful purpose anymore, given that now even the > pkg-config module can (and does) return absolute paths to the libraries. What harm does their presence cause? Please ask on the user list to see if people are using them. I suspect they may be used by some projects to link to special runtime libraries when cross-compiling. We'd need to make sure there is a better way for all such use cases before deprecating the commands. -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: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] RfD: deprecate link_directories() and link_libraries()
My dislike against these functions is probably known, and now I would like to bring this to a new level: I would like to formally deprecate these functions. I don't think they serve any useful purpose anymore, given that now even the pkg-config module can (and does) return absolute paths to the libraries. The plan is to introduce 2 new policies and whenever you set cmake_minimum_required(VERSION 3.13) and use these functions you will get a warning telling you to stop that nonsense. Thoughts? Eike signature.asc Description: This is a digitally signed message part. -- 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-developers
