Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2017-07-19 16:46:03

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