Re: [Boost-users] FindBoost.cmake does not check for include headers

Subject: Re: [Boost-users] FindBoost.cmake does not check for include headers
From: Roger Leigh (rleigh_at_[hidden])
Date: 2016-04-13 14:52:32

On 13/04/2016 18:37, j.wuttke wrote:
>
> my mail was not clear enough. I meant to use FindBoost through a command
> like
>
> find_package(Boost 1.48.0 COMPONENTS date_time program_options REQUIRED)
>
> i.e. I want to check the presence of *specific* Boost components.
> Needed e.g. under Debian, where users are free to install whatever
> subset of Boost.
>
> Package date_time has a header file named 'date_time.hpp';
> package program_option has 'program_options.hpp'.
>
> Isn't this long-term stable? Why not check for the presence of these files?

The names probably /are/ long-term stable.  The problem is that the 
naming isn't consistent between components, so we don't have a means of 
knowing unambiguously what to check for.  You're certainly right that 
date_time.hpp is fine, and filesystem.hpp and other components are also 
fine.  However, other components are not.  For example context, system 
and serialization are not.  Nor is wserialization.

It's for this reason that you would most likely need a component => 
header mapping.  Given that most header names are stable, it's most 
likely that we could skip a per-version mapping and just use a single 
stable header for each component.  It would require keeping up-to-date 
for every boost release in addition to the dependencies though.

That is certainly possible to do, but it does have a cost in that it 
increases the maintenance burden and already heavy complexity of 
FindBoost.  Since it solves a real problem, maybe that's worth paying 
though.  Hopefully one day the Boost developers might provide the 
configuration directly; looking into this is on my todo list but I find 
the boost build system rather impenetrable.

There's a ticket I need to look at regarding the imported target for 
just the headers; I can look at this at the same time.  I'm on holiday 
all this week, but I can probably find time next week to investigate 
what needs doing in more detail.

Kind regards,
Roger