[cmake-developers] [PATCH] FindBoost: Add imported targets
brad.king at kitware.com
Tue Dec 1 11:19:00 EST 2015
On 12/01/2015 10:58 AM, rleigh at codelibre.net wrote:
> I'd definitely like to see this for future Boost releases, though for
> historical releases we're a bit stuck. I'll revisit the work I pointed to
> and see if I can figure out bjam/boost-build and integrate this, since it
> would effectively give us CMake configuration "for free" off the back of
> the autolink data, and would also come directly from the compiler so
> wouldn't require parsing all the headers by hand.
Good. Once Boost provides that then our FindBoost script can switch
to looking for it when the version number is high enough.
> I've attached an updated version of the patch which does this. The
> behaviour is otherwise identical to the earlier patches. It's less awful
> than I expected--the information for many Boost releases was the same so
> it could be reduced in size significantly. This also includes a utility
> script to do the parsing, so it can be potentially used for future Boost
> releases as well. I've run the script against all versions of Boost
> supported by the script, and it's verified with the unit test for some of
> the components.
> The dependency parsing handles the case where the component library name
> matches the include directory name. For most cases, this is correct, but
> there are cases marked * where it isn't. These cases require the user to
> request the appropriate component name by hand with find_package (since
> the include directory name isn't a valid component name). For most cases
> we can't make the assumption since e.g. if you use <boost/archive> we have
> no idea which serialisation library to use; and if you use <boost/math> we
> don't know which of the math_* libraries you /might/ use. We have to
> leave that up to the user. Likewise for <boost/test>. For these
> libraries we also need to special-case the dependency info since we can't
> easily get it via the headers; currently only mpi_python needed handling
> in this way; the others have no dependencies.
Great. Please split this up into a few commits, perhaps:
- Add parsing script, perhaps `Utilities/Scripts/BoostScanDeps.cmake`.
I see it documents in the comments the need for special cases already.
Please also add a comment next to each special case to explain it.
- Run script to populate the table in FindBoost.cmake. Document in
the commit message the range of versions included.
- Add imported targets using the now-available tables.
More information about the cmake-developers