Am 19.07.2017 um 18:38 schrieb Ion Gaztañaga via Boost:
On 19/07/2017 18:08, Klemens Morgenstern via Boost wrote:
Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost.
Maybe it's just me, but paying for Boost.Build effort to better document it, clean it a bit and adding the feature of automatically generate CMake (and maybe the infrastructure to build system projects) and packagin utilities for major distros would be relatively cheap and extremely useful to easy the use of Boost.
That is just you. I give you the one on the the documentation, though it would be a stretch to claim CMake is any better in that regard. "adding the feature of automatically generate CMake" is a huge task and completely pointless, if boost.build works. Much better would be to extend the FindBoost.cmake with a small descriptions of the steps to build boost if required.
Like regressions test infrastructure, it's a basic building block for Boost so it should get a different treatment from other libraries.
And it's actually a tool used by people outside of boost. GIven the announcement it just got killed off, which could be a first. I mean boost maintains old libraries like boost.iostreams. Since we're not deprecating tools, why not also throw out some libraries?
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost