On 17 June 2015 at 20:50, Stephen Kelly <steve...@gmail.com> wrote: > 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 remember the discussion but did not realize that it was a tool supposed to be useful for any project. Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. By the way, in one of my project I end up using one FindBoost call with all the components needed by all the libraries of the project. I do this to avoid having to call FindBoost separately for every library with different components (still using the COMPONENTS option listing what the whole project needs). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. If I understand correctly, if FindBoost was supporting imported targets and using "Boost" as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. Is my understanding correct? > > > > 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. > > > 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, > Thanks for the pointer. > > 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
