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

[rleigh at codelibre.net]

> Thanks for working on this.  Please read through this mailing list
> thread:
>
>  IMPORTED targets for some Find modules
>  https://cmake.org/pipermail/cmake-developers/2014-June/010694.html

Done.

> On 11/16/2015 09:26 AM, Florent Castelli wrote:
>> But one there’s one thing that comes to mind. Some compiled libraries
>> have dependencies on other compiled libraries.
>> Don’t you think it would make sense to teach FindBoost about those
>> so we link everything properly?
>>
>> And also maybe add the native dependencies for some modules that
>> have one like maybe pthread or openssl.
>> Though, this might be hard to get right in a cross platform way.
>
> Please look at adding these.  The imported targets should come
> with all usage requirements as if they were provided by upstream
> Boost.  It may be tricky to get right on all platforms but if we
> do not do it then application code will have to do it instead.

I have made a first attempt at this.  I suspect it will need some
refinement, but hopefully useful as a starting point.  Please see the
attached patch.  I'd certainly be very appreciative of any comments.

I considered whether we would need to hardcode all the dependencies, since
some are known.  But since they can change from release to release, and we
don't know the complete set, I opted to do this automatically to ensure
it's correct (for some definition of correct) for any arbitrary Boost
release.

- This will iteratively discover all the potential dependencies for each
component via the header defines which would trigger autolinking on
Windows.  This is very aggressive and not all the discovered libraries may
be required under all circumstances, if e.g. a particular set of #defines
and headers must be used to pull in another component dependency, we will
pull it in anyway.  However, it is almost always going to link
successfully as a result.
- Any missing dependencies are automatically added to the component list
and as imported targets.

This makes linking correctly much simpler and much more transparent, as
demonstrated by the added testcase.

Problems and missing features:

- Scanning all the headers line-by-line is slow, and this is noticeable;
if I have read a file into a variable and converted it to a list, if there
was a way of filtering the list in a single pass, that would be a big
improvement.  We basically just want the #includes and library names, but
don't want to run two regexes on every line.
- I've had to special-case boost_bzip2 and boost_zlib since they don't
work under all (most?) circumstances.
- I've made boost_thread link with Thread::Thread automatically.  I'm not
a heavy user of all Boost library components, so other dependencies will
also require adding.
- Header-only components with implicit dependencies on components with
libraries are not currently handled; these could be added as imported
targets as a future improvement.
- You can now disable autolinking and enable shared libraries with
imported targets.  (Personally, I've never had autolinking work ever--it
can never find the libs!  Once the dependency discovery is fully
functional, we could potentially always disable it when using the imported
targets to give consistent linking behaviour on all platforms.)

In the mailing list thread you pointed to, there was some question over
FindBoost being compatible with the future modularised Boost libraries and
with Boost using CMake in the future.  These are reasonable concerns, but
personally I'd rather have something that works now with current and
previous Boost releases, since progress upstream is somewhat unpredictable
and leaves us in limbo waiting on them otherwise.  So long as the
modularised Boost cmake config files are compatible with the variables and
targets defined here, and to be backward compatible they would have to be,
won't they be automatically used instead of FindBoost when installed? 
Unless I'm missing something, upstream could make the modularisation
completely transparent if they care to be backward compatible with what is
already in wide use.


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