Dave Abrahams wrote:
Except that there are interdependencies among some of the libraries. How many build tools should you need in order to install Boost.Serialization?
Currently boost serialization needs only one tool to build/test - Bjam. The rest of the dependcies are header only. I don't know, but boost serialization might be buildable/testable with CTest. I don't think that's a huge hill - certainly not greater than the current situation. (aside, starting in 1.46, testing the serialization library now also depends onthe filesystem library which is also compiled)
I see the centralized functions being limited to: a) reviews/certification b) accumulation of testing results c) coordination/maintainence of standards (a-d above) d) promotion of developer practices compatible with the above (licenses, etc).
Suppose such an environment existed today. The whole issue of moving to git wouldn't be an issue. Each library author could use which ever system he preferred. Movement to git could proceed on a library by library basis if/when other developers were convinced it was an improvement. It would be one less thing to spend time on.
Or, it could be one more thing to spend time on.
Standardization != coordination, and while coordination can slow things down, standardization brings efficiencies.
It is unbelievable painful for me to say this, but I think we're in agreement here. I'm proposing that we "standardize" things like namespaces, directly structure, testability requierments, documentation requirements, platform support requirements, etc. BUT that we try to move away from having to coordinate so closely - e.g. making a giant release on a specific date. Robert Ramey