On 12.04.2016 12:09, Robert Ramey wrote:
But I don't believe that the build tools have to be imposed from top and I don't believe that we have to exclude all other build/test alternatives. Each library author chooses his documentation system and each one chooses his test system, (Boost test, lightweight test, home brew, etc). At times this is inconvenient, but it all in all it works pretty well. I see no reason that library authors can't include a CMake directory in their libraries just as they have a build directory which supports boost build. Users can select the one they want. Boost build is requirement only because we want to support centralized monolithic testing. Personally I would like to see us consider more distributed testing on an individual library basis - but that's another battle.
Amen to all of the above ! I would even go a step further: to me true modularization (as we have discussed many times in the past) includes the *ability* to have a library be able to be built (and potentially released) stand-alone, against all its prerequisite components already installed. I still have plans to work on that for Boost.Python (which luckily has no runtime dependencies on Boost, making this relatively easy). I'm also moving away from Boost.Build, as I keep having trouble setting it up for my needs. (Note: I'm not criticizing the Boost.Build developers. I much appreciate their work. But that alone can't be reason to use the tool.) So, I think it would benefit all of Boost if more developers would start thinking of Boost libraries as separate projects, who may or may not want to share a common infrastructure for building, documenting, and testing. It's great that those tools are available, but they mustn't be imposed on individual projects. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...