[cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh at codelibre.net]

> On 11/30/2015 11:54 AM, rleigh at codelibre.net wrote:
>> I do worry about the maintenance burden of hardcoding the information in
>> the script.
>
> I do too.  We already have to update the script for each Boost release.
> This is among the reasons the work is better integrated with upstream
> Boost instead.

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.

>> How should this cater for dependency changes between boost releases?
>> How far back in time does this dependency information need to go?
>
> One would need to fill out tables per version and then detect the
> version to populate the info.  Just don't provide imported targets
> if the version does not have dependency info available.  If someone
> needs it they can run something to fill out the tables for their
> version and submit a patch.

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.

Just FYI, the boost components in 1.59 are as follows:

Header          Library             Mismatched name
--------------- ------------------- ---------------
archive         serialization       *
archive         wserialization      *
atomic          atomic
chrono          chrono
container       container
context         context
coroutine2      coroutine           *
coroutine       coroutine
date_time       date_time
endian          endian
filesystem      filesystem
iostreams       iostreams
locale          locale
log             date_time           (*)
log             log
log             log_setup
math            math_c99            *
math            math_c99f           *
math            math_c99l           *
math            math_tr1            *
math            math_tr1f           *
math            math_tr1l           *
mpi             mpi
mpi             mpi_python          *
program_options program_options
python          python
random          random
regex           regex
serialization   serialization
signals         signals
system          system
test            prg_exec_monitor    *
test            test_exec_monitor   *
test            unit_test_framework *
thread          thread
timer           timer
wave            wave

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.

The above isn't really a problem, it's just something to be aware of which
limits just how user-friendly we can make things.  The granularity of the
FindBoost component selection means the user will need to know which
libraries they need when they use certain headers; but this was already
the case for the variables, and is no different for the imported targets.


Regards,
Roger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FindBoost-Add-imported-targets.patch
Type: text/x-diff
Size: 27799 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151201/8a5d3741/attachment-0001.patch>