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