
On Mon, Feb 7, 2011 at 7:39 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Mon, 7 Feb 2011 12:27:21 -0000, John Maddock wrote:
http://svn.boost.org/svn/boost/sandbox/library-name/boost/ http://svn.boost.org/svn/boost/sandbox/library-name/libs/
The planned/proposed organization is roughly like the latter. If you want to look at the organization in detail, see https://github.com/boost-lib/boost
Nod, either could be supported by Boost.Build trivially provided there's a complete (integrated) release tree sitting around somewhere - otherwise as you mention the compiler command paths get stupidly long....
I don't know what you mean by "complete (integrated) release tree", but we're not planning to do that. We're only planning, as part of the build process, to generate forwarding headers in an integrated include tree
By "we", do you mean ryppl? I've gone through the process John Wiegley kindly sent me: Grab the supermodule: git clone git://github.com/boost-lib/boost.git Then 'cd' into the "boost" directory it created, and run: git submodule update --init Then continued as described here: http://ryppl.github.com/gettingstarted.html That produced a completely new tree with the forwarding headers, not under version control. It seemed oriented to what a user might want. What about a library developer? What does the tree structure they work with look like? How does integrate with their development repo? I guess the non-version controlled tree produced by the above could be used as a "complete (integrated) release tree", but I'd like to know the specifics, and give them a try. Thanks, --Beman