Re: [boost] [Boost Library Incubator] Unable to submit library

Subject: Re: [boost] [Boost Library Incubator] Unable to submit library
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-21 09:13:28

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 locally.
>>> 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 know) 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 PITA.
>
> 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 big.
>
> 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 reason I put it in for my VMD library is because it is on the Boost 
review queue, so I am trying to make it easy for someone who might be 
interested in the library to look at 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 docs.

While I think it is an advantage of the Boost Library Incubator that 
someone should be able to see the docs directly from the website, anyone 
interested enough in a library should be willing to clone it locally and 
regenerate the docs.