On Tue, Jan 6, 2015 at 9:56 AM, Beman Dawes
On Tue, Jan 6, 2015 at 10:37 AM, Peter Dimov
wrote: Beman Dawes wrote: ...
* 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.
Understood.
I'm hoping that Boost.Build itself is the same for either distribution directory structure, and that the only thing that differs <boost-root>/Jamroot and perhaps some of the other <boost-root> scripts. Maybe the differing files could like in a different boostorg repo or a different boostorg/boost branch.
+1 And we already have project build scripts that perform differently based on the repo structure they execute in. I'm referring to Predef. I normally do not develop and test Predef inside the regular Boost tree. Instead I work on it totally standalone (except for the external Boost Build tree). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail