Hi,
On Freitag, 25. August 2017 11:21:50 CEST Robert Dailey wrote: > However, what I'm wondering is even though the import targets should > contain all information about include directories, libraries, etc, > should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES > variables? This depends very much on the target audience of your config.cmake file. My personal opinion is that you can skip those variables entirely for new projects. (Somebody please correct me if I'm wrong!) > It seems like Module packages are being deprecated > in favor of Config packages, because it puts the responsibility of > maintaining find package logic on the upstream maintainer (config > package) instead of on CMake (module packages it ships with). Yes. This has been the case since cmake 2.8 or so. A general rule of thumb for module vs. config: If you are the upstream: create a config package. If the upstream is somebody else, but uses cmake: submit a patch and get them to provide a config package. If the upstream does not use cmake: they can still provide a config package. If all else fails: add a module to your project to find the upstream library. Cheers, Johannes P.S.: And yes: creating a config package has a steep learning curve. Link [2] has all the information you need, but it is hardly a nice tutorial... -- 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
