[cmake-developers] [PATCH 5/5] FindBoost.cmake: Add Boost::boost and Boost::<C> targets and documentation

Philipp Moeller bootsarehax at gmail.com
Tue Jun 24 09:46:07 EDT 2014


Stephen Kelly <steveire at gmail.com> 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::?




More information about the cmake-developers mailing list