On 12/04/2017 05:55, Robert Ramey via Boost wrote:
// example using he safe numerics library
#include <iostream> #include <limits> #include <boost/integer.hpp>
#include "../include/cpp.hpp" #include "../include/exception.hpp" #include "../include/safe_integer.hpp" #include "../include/safe_range.hpp"
This has raised consternation in some quarters - but I don't see anything wrong with it. It basically means that only the <boost libraries are depended on the whole b2 business. I didn't want the incubator version of the the safe numeric library to depend on the library having been accepted into boost have have b2 run. Also I don't like adding the library to boost - and having to change all the headers. What if someone want's to run the tests/examples outside of the boost tree.
While I agree with this practice in general, in the specific case of Boost libraries using ../include relative paths is not a good idea, in my view. The problem with this is the way the source is repackaged as a monolithic zip/tarball -- all of the include directories are removed and replaced with a "boost" folder that combines the include directories from all libraries. Thus an end user who only uses this zip/tarball version of Boost cannot build your tests/examples without modifying the source to use <boost/...> includes instead -- so this is what you should have used to begin with. Having said that, as long as the library isn't actually part of the Boost distribution yet it might be more convenient to keep relative paths (since the headers don't get moved), but it's one more thing that needs to be fixed up later.