Paul A. Bristow wrote:
I'm still struggling to understand the value of the benefits, compared with those risks.
You don't see how unusual it is to have the include directory point to the root of the distribution, instead of pointing to a directory with header files, as is the case with Everything Else?
I've been using this environment for a while and haven't encountered any breakages.
What about all the existing Visual projects and solutions?
All existing Visual Studio projects and solutions, and everything that still points its include directory to the Boost root, will (should) continue to work because of the symbolic link from $BOOST_ROOT/boost -> $BOOST_ROOT/include/boost, which I've proposed for this purpose.
I worry that even your extra environment variable for 'legacy stuff' will cause trouble.
I don't see how, given that I'll probably be the only one using it. :-)
Having been told by David Abrahams that environment variables are evil, and getting rid of $BOOST_ROOT references, it now seems that they will be essential.
Projects that put $BOOST_ROOT in their -I path do that because they try to support a structure in which their directory is not under $BOOST_ROOT. I'd argue that for such projects using $BOOST_INCLUDE instead is more correct and more descriptive. Projects that refer to ../../../.. would do nothing while we continue shipping the headers in boost/ in monolithic releases. If we change releases to ship headers in include/boost/ or to not ship headers in a central location but require a "b2 headers" step, those projects will have to be changed to refer to ../../../../include.