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-20 10:10:23

On 7/20/2014 2:03 AM, Robert Ramey wrote:
> Edward Diener-3 wrote
>> On 7/19/2014 5:22 PM, Robert Ramey wrote:
>>> Coincidentally I was tweaking this area of the web site - should be OK
>>> now.
>>>
>>> I also fixed up the links in the form -
>>
>> How did you figure out to setup all those links ? Was all that available
>> to me on GitHub but I did not realize it ?
>
> yep
>
>>>
>>> For those who prefer instant gratification (as I do), I fixed the
>>> documentation link to point to the master branch html documentation.
>>> Browsable html documentation is a requirement of the web site.
>>
>> Where did that string come from ? It works beautifully but I have no
>> idea from where that gets generated.
>
> I forgot where I found that.  I copied the link from Safe Numerics then
> altered it to point to your documentation.

Actually when someone clones my library, the top-level index.html 
redirects to the index.html in the html sub-directory.

> BTW, if you want your docs
> to look like boost ones, all you have to do is add the appropriate *.css
> and image files to the html directory.  Again, check safe numerics to
> see how this works.

All those *.css and images become redundant when someone clones my 
library from GitHub under their own local modular-boost. That is why I 
do not include them in the html sub-directory.

>
>>>
>>> I fixed up the issues to point to the issues page for this library in Git
>>> hub.
>>
>> That I can see on the GitHub sight. Am I supposed to fill that out myself
>> ?
>
> What I do is invoke the issues from the git hub website and copy the URL.
> Then I paste this URL into the submission form

I see the issues page on GitHub now.

>
>>>
>>> I fixed up the download link to point to the github created *.zip file.
>>
>> How did you generate that zip file on GitHub ?
>
> same as above

I see that now on my library's GitHub page.

>
>>>
>>> So you should be in business - good luck with this.
>>
>> Thanks very much ! Evidently I have no idea all those facilities were
>> available on GitHub, evidently somewhere.
>
> The whole idea of the incubator is to provide a uniform facade to all the
> facilities that a boost library needs with the minimal disruption possible.
> So if one already has his own trac equivalent, he can just point to that.
> I started this before we made a big commitment to git.  It was a happy
> coincidence that it is a good match.
>
>>> Though not strictly a requirement, consider implementing the test
>>> dashboard.
>>> Different authors have addressed this in various ways.  Look at my advice
>>> how to do it and and look at other authors usage of continuous
>>> integration
>>> websites.

I will look at it.

>>
>> I have tests for the library that run under modular boost in the test
>> subdirectory using bjam/Boost Build. Is the test dashboard connected to
>> those tests somehow ?
>
> I struggled with this.  The website requires tests for a library to be
> included
> but there was no obvious way to get something like the boost test matrix
> without turning this thing into a really big job.  Also any system I might
> run wouldn't scale.
>
> After a lot of time learning to understand CMake, I got it working to my
> taste for safe numerics and wrote the instructions in my Simple Tools
> advice.  I prefer this to boost build for a number of reasons - not the
> least
> of which it creates a project in my IDE.  It also permits.  CMake can
> create a project which posts the results to a test dashboard which they
> run on their own website.  I've described how to do it in the documentation.
> I like this because it lets those who use a library to test it in their own
> environment
> and post the results to this common area. It means that the platforms being
> used is the same set as platforms being tested.  And it's totally scalable!
> And
> it zero work for me or anyone else.

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.

>
> Other libraries such as AFIO have used some "continuous integration"
> websites
> with what looks like good success.  Pretty soon I'll lean on the authors to
> write
> a page with instructions (for dummies) on how to set it up.  You can see
> this
> in action by clicking on the test dashboard link for AFIO, DI and others.
>
> The fact that I was able to put all this together with relatively little
> effort
> suggests to me that we're at the dawn of a new era for boost.  One where
> it's much easier to get a library ready for review without sacrificing our
> standards.  Lets hope so anyway.

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.