From: "Paul Mensonides" <yg-boost-users@m.gmane.org> "William E. Kempf" <wekempf@cox.net> wrote in message news:20030108172855.VIMZ4411.lakemtao01.cox.net@smtp.east.cox.net...
I believe that he is talking about the root Boost directory which is the parent directory of the Boost headers. If, for instance, I have a directory "include" that I want to put all my library headers in and have a single environment variable to specify the header search paths. This cannot be done with Boost because the Boost headers are located at "boost/boost/*.hpp", not "boost/*.hpp". Furthermore, you can't even put Boost in the same directory as other includes, because you might get a conflict between "include/boost" and "include/boost/boost". It doesn't bother me personally, but I see the point that he is getting at.
If that's the point (which doesn't seem to be, since he talks about "new boost libraries" doing the right thing), I can't agree. Moving Boost headers out of a boost subdirectory and into the top-level include directory (so <boost/shared_ptr.hpp> becomes <shared_ptr.hpp>) would only result in name clashes with other headers.
That is not what he (or I) means. He is suggesting that the path to "shared_ptr.hpp" should be "$INCLUDE/boost/shared_ptr.hpp" rather than "$INCLUDE/boost/boost/shared_ptr.hpp", which is the way it is now. Everything would still be the same for including headers except that only a single search path is necessary to setup with the compiler.
That's the way it is now *only* if you set your include directories incorrectly. When they are properly set to $BOOST_ROOT then it's only <boost/shared_ptr.hpp>, not <boost/boost/shared_ptr.hpp>. William E. Kempf wekempf@cox.net