Stephen Kelly <[email protected]> writes: > Brad King wrote: > >> On 06/20/2014 01:09 PM, Philipp Möller wrote: >>> +# Boost::boost - interface target containing the >>> include >>> +# directory >> >> Nice. > > > Note that Boost upstream is modularizing and may provide CMake config files > in the future: > > https://github.com/boost-cmake/boost-cmake > https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus > > The wiki page is out of date, and so is the repo, because boost is trying to > make a release before finishing the modularization work and it is all on- > hold for several more months.
This project has been going on for ages and considering how long it took Boost to change their SCM or the (stalled?) ryppl and 0install efforts I don't see this happening anytime soon. I'm of course not belittling any of those efforts or the people behind them. Huge organizations are hard to move and those that try deserve respect. It would certainly make my life easier if they succeeded. Exporting targets with proper dependencies is a problem now and lots of projects depend on Boost. Improving the process now and even supporting older versions of Boost is, IMO, worthwhile. > This means: > > 1) Creating a Boost::boost monolithic target may not be appropriate IMO, even a modularized boost build should provide a target that just gives you all of the includes for convenience in addition to more fine-grained access, but I see why one would think otherwise. > > 2) If FindBoost creates imported targets named Boost::*, then config > files provided by boost upstream probably can't use that namespace > (currently it uses boost::, but you might consider whether imported > targets provided by files shipped with cmake should use CMake::). Yes, I was thinking about that. So far I have only applied those changes for packages which are highly unlikely to ever provide package configs and so giving them their own namespace made sense to me. Their is also a problem that some find-modules don't use other find-modules even where they should (e.g. FindGLUT which is using Xmu and Xi, which could be provided by FindX11). This could lead to inconsistencies between targets, thus the encapsulation in the GLUT namespace. Boost is a bit of a special case and changing the namespace to indicate that one is using the CMake provided targets might be a good idea. What about FindBoost::? -- 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-developers
