Re: [boost] [Git] Moving beyond arm waving?

Subject: Re: [boost] [Git] Moving beyond arm waving?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-02-07 20:52:09

At Mon, 7 Feb 2011 08:28:56 -0500,
Beman Dawes wrote:
> 
> On Mon, Feb 7, 2011 at 7:39 AM, Dave Abrahams <dave_at_[hidden]> 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 guess so.  At least, I haven't heard of anyone planning to do it differently.

> 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. 

Yeah, but to be clear: just a header tree, not the full Boost distro.

> It seemed oriented to what a user might want.

IIUC, Marcus has already made the separate header-generation step obsolete, so
it now happens automatically if you have his changes, which are here:
https://github.com/boost-lib/boost/commits/1.45.0

> 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.

Once you have Marcus' header generation, that would work perfectly.  Until then,
it will probably work just fine, but you might have to explicitly build the
GenHeaders target if your library's set of header paths changes.  You might want
to consider putting the individual include/ directories of the libraries on
which you're working
(e.g. https://github.com/boost-lib/filesystem/tree/master/include) in your
#include path ahead of the generated headers to avoid that I guess.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com