Beman Dawes wrote:
* The directory structure installed by users via the traditional monolithic "Getting started..." zip file procedure. Because users may have a large investment in setups that assume this traditional directory structure, any change would be painful. We need to continue to ship this directory structure for long enough to give users a chance to smoothly transition to any new structure.
Note that in the .tar.gz/.tar.bz2/tar.xz case we can use include/ for the headers and put a symlink boost -> include/boost in the archive in order to not break existing uses. In fact, for the tar files, we can even leave the headers in libs/*/include and ship symlinks in include/, to faithfully mirror the source tree. Which will allow boostdep to work. :-) We can't put a symlink in .zip or .7z though. :-(
* The directory structure installed by a Boost Package Manager, i.e. bpm. The introduction of a new modular way to install Boost is the ideal time to introduce a new install directory structure. Now. Not later. Don't release bpm for production use until we are happy with the directory structure it will install.
The problem here is obviously that the version of Boost.Build installed by bpm would need to support the new directory structure. When the two structures (source tree and bpm) are the same, or supported by the same Boost.Build, the package script can just "tar cf build.tar.lzma tools/build/ Jamroot boostcpp.jam libraries/Jamfile.v2" from the source tree, and call it a day. But if the bpm structure requires a custom version of Boost.Build, (a) the package script would have to do more work and (b) this custom version of Boost.Build will need to be tested separately. In the same structure case, the packager may (reasonably) assume that Boost.Build has already been tested. PS: Beman, you have an open pull request in system for meta/libraries.json.