I think we want to keep it a separate library from algorithms for compatibility with modular boost. boost/libs/spreadsort is fine with me.
On what do you base that conclusion?
Based on the fact that I know how to build the library and copy it into the boost tree in the modular boost fashion, but don't know how to do the same from inside the algorithms directory.
An alternative structure would be to have a boost/libs/sort/spreadsort structure, but in that case I'd be maintaining future sort contributions in addition to spreadsort to keep it one coherent library (which I'm willing to do).
Thanks for offering to do that. However, I fail to understand how you think multiple sub-libraries under boost/libs/sort will be more tenable than the same under boost/libs/algorithm/sort.
There is a lot of code under algorithm. Synchronizing a few sort algorithms into a release version seems simpler than synchronizing all of algorithm. Please correct me and explain how it's done if I'm wrong.