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