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

Roger Leigh rleigh at codelibre.net
Tue Nov 17 03:48:38 EST 2015


On 17/11/2015 07:53, Ruslan Baratov wrote:
> On 16-Nov-15 21:01, rleigh at codelibre.net wrote:
>> I have attached a patch to add imported targets to FindBoost, in the form
>> of Boost::<component> (e.g. Boost::date_time) or Boost::Boost as a
>> generic
>> interface library for header-only components.
> Since it's `Boost::date_time` I expect that it will be `Boost::boost`
> (lowercase).

Yes, I've merged most of the previous work Brad pointed to yesterday, 
and this included this change.

> On 16-Nov-15 21:39, Brad King wrote:
>> 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.
>>
>
> One tricky part about it is that dependency can be optional. I.e.
> Boost::iostreams may or may not depends on ZLIB/BZip2. Such information
> is known only by build procedure. I.e. should be installed by b2 itself
> or by wrapped ExternalProject_Add instructions.

For the specific case of the zlib/bzip2 dependencies, this is only the 
case when using the static libraries?  It's not exposed via the headers 
is it?

Looking at the information embedded in the sources for use with 
autolinking, we could certainly process the headers for the requested 
components and pull out the referenced libraries.  This would get us all 
of the header dependencies without hardcoding anything ourselves, which 
would make it work with arbitrary versions of boost without having to 
hardcode the differences between Boost versions.

Fully supporting static linking would be much more difficult.  As you 
say, it depends upon how Boost was built.  Full support here would need 
to wait for the upstream to generate this data at build time?


I'll have a look at doing the above and should have an updated patch soon.


Regards,
Roger


More information about the cmake-developers mailing list