On Sat, Jan 3, 2015 at 4:12 AM, Vladimir Prus
On 12/31/2014 06:28 PM, Peter Dimov wrote:
Typically, when some library is installed in, say, $LIB, its headers reside in $LIB/include and its .a/.lib files in $LIB/lib. Our libraries, when built, go to $BOOST/stage/lib, which is close enough. But our header directory is just $BOOST, which doesn't seem right, as the whole of Boost is accessible through it. It makes sense, at least to me, to have the headers in $BOOST/include/boost, instead of just $BOOST/boost. The transition to Git would have been a good time to switch to that - there were enough other changes to the structure.
I'm not saying that we should switch right away or something like that, but am I the only one to whom such a switch (at some unspecified time in the future) seems a good idea?
Personally and theoretically, I'm ambivalent here. We never had any practical issues with the current layout, and 'stage' is not 100% equivalent to installed package, and one can argue that $BOOST/stage/include might be a better location than $BOOST/include, or that $BOOST/stage/lib should be changed to $BOOST/lib (and then everybody will be confused bewteen "libs" and "lib", so maybe we should rename "libs" to "components"), but the change you propose is also logical and easy to make.
The only important aspect though, speaking as release manager, is that if we change this now, we'll likely break a huge number of user build and automation scripts that expect current layout, lots of instructions on the web using current layout, and so forth. That's easily person-months of pain. Do we want it so badly?
I feel very strongly that we need to continue to ship the current .zip/etc files on SourceForge with their current structure so that all user scripts, including those that use b2, continue to work. I see a new directory structure as something generated by Peter's Boost Package Manager (aka bpm). It may well install some new top level Jamfiles and bootstrap scripts. Or maybe there will be a new "packaged-boost" top level super-project. But that's not clear yet. --Beman