Boost logo

Boost :

Subject: Re: [boost] [Boost Library Incubator] Unable to submit library
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-20 15:58:35


On 7/20/2014 12:59 PM, Robert Ramey wrote:
> 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.

That's fine since you figured out how to show the documentation that is
in the library at GitHub.

>
> b) If I have an interest in a library, I like to see reviews by others
> regarding
> their experience - again immediately. This is addressed by using the
> facilities
> in the of wordpress web development to permit comments and boost style
> reviews - and # stars rating info - on libraries not part of boost.
> So this issue is resolved for me.

Reviews and responses are great.

>
> c) When evaluating a library, I like to be able to test it. Currently only
> libraries already in boost are tested by our system. And our system
> requires dealing with boost build and all it's problems. In spite of the
> heroic efforts by boost build developers, it's just to big a hill to climb,
> too soon for one who want's to make a library which might not be
> accepted. the Incubator requires tests - but it does not require any
> specific testing/building setup - e.g. boost build. Certainly, boost
> build fulfills the requirement - but other systems to also. After much
> time investigating alternatives - I'm recommending that library
> submitters use CMake in the manner that I have described in the
> Advice/Simple Tools section. Not perfect - but along with the
> information I provided - provides the simplest and most expedient
> way to get the job done and fulfill the incubator requirements.

I give specific instructions how to test the library with Boost Build.

>
> d) When evaluating a library, I would like to immediately see test
> results on a variety of platforms, compilers, etc. Boost testing dashboard
> only displays results of libraries already in boost - so it's no help.
> Turns out that CMake has this facility. It is hard to figure out from
> the CMake documentation (another problem) but I've included
> detailed instructions on setting this up along with an example
> using safe numerics. So that's what I'm recommending personally.
> Other library submitters have used other means to fulfill the requirement
> for a testing/deployment method. And I have no problem with that.

I do not think it is very important to see test results online. It means
next to nothing unless you can look at the tests themselves and
understand what they are doing. In my library running the Boost Build
tests locally gives the results and you can use any compiler supported
by Boost Build. I am not going to invent another way of testing just to
show some results online. Anybody who is really interested in a library
should not be so lazy that they are not willing to clone it locally and
try it out.

I am not saying I may not look at your CMake/CTest/CDash combo at some
time, but if it is an absolute prerequisite for having a link to online
test results in the Boost Library Incubator I would rather remove my
library. Dealing with Boost Build is hard enough. Spending much time on
yet another set of underdocumented build tools, and trying to figure out
how they work together just to be able to specify some URL of test
results, is too depressing for me to think about. It is not your fault
that nearly all of the people who create build and/or tests systems are
so poor in explaining how they work, but it seems that is always the case.

>
> So that's the rationale behind how we got to where we are today
> on this. It might be helpful to remember that the incubator is
> different than boost in that it has a much looser structure. It doesn't
> prescribe methods - only requirements. The web site is really
> a facade to make the various ways of fulfilling the requirements
> look more uniform and impose some (but not too much) structure
> on the process of library development.
>
> It's a work in progress. I much appreciate the feedback from all
> parties working with this system - it's a great help. Thats why
> I love boost - it makes me a better person.

I think your site is a great idea but aside from someone putting their
library there and hopefully responding/discussing other people's
comments, suggestions, queries etc. I think the less you require of a
library submitter the better. If others are too lazy to follow
instructions for using the library locally then that is their problem,
not that of the library creator. In fact I think you should have another
field in your Library Submissions page: something like "how to use the
library and any other comments the library submitter would like to make
about his library for the benefit of end-users".


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk