On 19/06/2017 0:05, Robert Ramey via Boost wrote:
Actually, I already proposed this some time ago. In fact we already have much of that. For example, for bugs some libraries use git issues while others use the traditional system. Each library chooses it's own documentation tools. The git submodule implementation could be seen as each library having it's own VCS just tied together at the top.
We have both the old a the new bug system, but no library uses Bugzilla for that. That said, I would like to migrate all the old issues from track to github. I prefer a trac-style bug management system instead of pull requests, but unification has many advantages. Common tools help maintenance and collaboration between boost developers and any abandoned library can be rescued because all used tools are familiar. They help reviews. Documentation is a different issue, we can't compare the coupling between libraries to the different documentation styles. In any case, many Boost libraries use Quickbook or Boostbook which IMHO should be encouraged.
I don't like each library to use a different build tool (CMake, SCons, etc...) I like the fact that I can write my test jamfile triggers the creation of any dependent library just because all of them use bjam and
we're not talking about what you want to do as a boost developer. You can do whatever you want. The question is should you, boost or anyone else tell developers of other libraries what they should do?
Boost is voluntary organization. Organizations have rules that try to help the goal of the organization. If you want to call you library "Boost" you need to follow the rules. This makes a lot of sense to me. I could release my library directly in Github, but following Boost rules my library is interoperable with other libraries, and my dependencies don't break often. It's not as flexible as I might want but it has a lot of advantages. If each library is free to choose the build system, release dates, track system... what's the point of naming it "Boost"? Just because they were reviewed in the boost mailing list? I need to build several Boost libraries as my library depends on them. Do I need to learn different build tools just to run my tests?
other Boost libraries are designed to act friendly with my library.
Right - but only at the source code and local build level. For users using a portion of boost in their apps, they don't see it this way.
If you want to have a Boost library you need to maintain the style and rules of Boost.
Hmm - boost has a lot of rules related to the source code, directory structure, requirements for tests, etc. I don't see this as being impacted.
The impact on how other libraries build, name, find dependencies, ... is much more important to my library than how the source code of those libraries is written. I understand that some aspects of Boost don't work as desired/expected, but I doubt any "modularization" that allows different build/trac systems will solve them. IMHO the entropy can only increase. Best, Ion