Klaim - Joël Lamotte wrote: > I didn't realize at all that the FindPackage way is supposed to be > obsolete now.
It is not obsolete, but it is not a good approach (since CMake 2.6.0 already) if the upstream uses cmake, because config file packages provide a better experience for downstreams http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html Even for upstreams that do not use cmake, it is preferable to generate config file packages for a good downstream experience for cmake users. That is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it too: http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 > I'm quite surprised actually. We prefer not to accept new Find modules into the cmake tree because that puts the maintenance burden on us, and because it is an inferior user experience. Some new Find modules still get in, but they need to have a reason to get in. > Ok I'll check PackageConfig.cmake for my new and even current projects > if it can help with managing the tons of libraries I work on. Do please let us know how that goes. > I will consider providing patches, if I can spend time on this once and > not bother > later it would help a lot. Documentation here explains how to do that for Find modules: http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module Thanks, Steve. -- 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
