Subject: Re: [boost] [Boost Library Incubator] Unable to submit library
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2014-07-21 09:21:06
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener
> Sent: 21 July 2014 14:13
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost Library Incubator] Unable to submit library
> On 7/21/2014 7:02 AM, Paul A. Bristow wrote:
> >> -----Original Message-----
> >> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of
> >> Robert Ramey
> >> Sent: 20 July 2014 17:59
> >> To: boost_at_[hidden]
> >> Subject: Re: [boost] [Boost Library Incubator] Unable to submit
> >> library
> >> Edward Diener-3 wrote
> >>> On 7/20/2014 2:03 AM, Robert Ramey wrote:
> >>>> Edward Diener-3 wrote
> >>> I think you can appreciate that having to duplicate tests which
> >>> already exist through bjam/Boost Build when the user clones the
> >>> project is not something I really want to do. I really don't see the
> >>> big deal of someone interested in my library cloning it locally
> >>> under modular-boost and then having all the documentation and tests
> >>> I explain very carefully in my top-level *.txt files how to do all this.
> >> There's no disagreement here. That's exactly how I envision that
> >> this site be
> > used.
> >>> I do appreciate the work you put into it. But I think that anyone
> >>> interested in a library in the Boost Library Incubator sight should
> >>> be trying it out locally just like everyone does with Git projects.
> >> There's no disagreement here either.
> >> But there are a couple issues you've left unaddressed.
> >> a) One looking for a library can only find documentation for
> >> libraries already
> > in
> >> boost. For the sandbox one had to download the package and
> >> (maybe) build the documentation in order to see the decimation. For
> >> me this
> > was a
> >> big problem which I addressed by requiring browsable html
> >> documentation. The github method - (has a minor/temporary problem - I
> is perfect for this.
> > It
> >> means one can browse the documentation immediately.
> >> So this issue is resolved for me.
> > The issue of generated (mainly html) files in GIT is still a nuisance.
> > If you are a sole developer, then it is quite easy - you simply
> > include all the /doc folder with /html etc in GIT.
> > But if you are developing *with* someone else, these generated files are a
> > You have keep reverting the /html files every time you want to GIT pull.
> > And you have push the updated docs every time too - and these may be quite
> > I don't see a better way round this yet. Ideas?
> I do not think that generated HTML documentation should be in Git. The only
> I put it in for my VMD library is because it is on the Boost review queue, so
> trying to make it easy for someone who might be interested in the library to
> the documentation without having to create it themselves. But really, with the
> proper jamfile in the docs directory, anybody should be able to recreate the
> While I think it is an advantage of the Boost Library Incubator that someone
> be able to see the docs directly from the website, anyone interested enough in
> library should be willing to clone it locally and regenerate the docs.
Historically, building the docs has been a step too far for most people.
Unless the build process can be fully automated, it's just not going to happen -
not just to peruse a library that may never make it.
I think that until we have fully digested modular-GIT, that's not going to
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk