FindBoost.cmake does not check for include headers
As per cmake 3.5.1, FindBoost.cmake does not check for include headers. Therefore it will give false positives - if a Boost project that only consists of a header file is not installed - if only a libboost* is installed, but not the headers from the corresponding *-dev package. I raised this issue long ago on the cmake bug tracker, and recently again on the cmake mailing list, but got no response. Would perhaps somebody from the Boost community volunteer to look into this issue? Or has already looked into it and could tell us what the problem is?
On 13/04/2016 16:14, j.wuttke wrote:
As per cmake 3.5.1, FindBoost.cmake does not check for include headers. Therefore it will give false positives - if a Boost project that only consists of a header file is not installed - if only a libboost* is installed, but not the headers from the corresponding *-dev package.
I raised this issue long ago on the cmake bug tracker, and recently again on the cmake mailing list, but got no response. Would perhaps somebody from the Boost community volunteer to look into this issue? Or has already looked into it and could tell us what the problem is?
I'm not sure of the historical reasons, but I can state that the reason we don't check for individual component headers is because that would require maintaining a static mapping of every component to header(s) provided by that component *for each version of boost*. This would be exceedingly hard to do; it's already at the limits of the reasonable and/or possible maintaining the autogenerated dependency information. That said, if there's any obvious header present in every released version of boost which is uncondititionally present for every boost build, I don't see why we couldn't add that to check for some basic level of availability. Candidates include: boost/any.hpp boost/array.hpp boost/bind.hpp boost/config/abi_prefix.hpp boost/config/abi_suffix.hpp boost/config/auto_link.hpp boost/cstdint.hpp boost/limits.hpp boost/mem_fn.hpp boost/operators.hpp boost/optional.hpp boost/preprocessor.hpp boost/rational.hpp boost/ref.hpp boost/scoped_array.hpp boost/scoped_ptr.hpp boost/shared_ptr.hpp boost/type_traits.hpp boost/version.hpp These are in every version from 1.33 to 1.60. We can test some or several of these; we need to be sure they won't be removed in a future release though. boost/config/auto_link.hpp is a safe bet, as is boost/version.hpp. Most of the above most likely. Regards, Roger
Sorry, Roger, 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? Best regards, Joachim
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
On 2016-04-13 18:37, j.wuttke wrote:
Sorry, Roger,
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?
Just for the record, for the original query on boost-users, there is now a patch ready for testing to address this: http://public.kitware.com/pipermail/cmake-developers/2016-May/028358.html Regards, Roger
participants (3)
-
j.wuttke -
rleigh＠codelibre.net -
Roger Leigh