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. 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. 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. 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. 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. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Library-Incubator-Unable-to-submit-... Sent from the Boost - Dev mailing list archive at Nabble.com.