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