Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Gary Furnish (gfurnish_at_[hidden])
Date: 2017-07-27 04:01:13

For whatever its worth as a user for 12 years, and someone who would
like to contribute more then a rare bugfix, I'm glad the SC stepped
in.  I've observed from the outside that basically no one was ever
going to touch boost.build because the people who like it (who happen
to be single points of failure for the entire boost ecosystem)
basically out-shouted everyone whenever a technical discussion came
up.  Its not like there haven't been concerns about boost.build for
years.  Its not like the documentation for boost.build wasn't
basically "ask the mailing list or prey someone else has asked stack
overflow" for years.  Its not like every time a new version of MSVC
beta comes out boost.build doesn't break and its not a priority
because the maintainers of boost.build don't use MSVC.  Its not like
everyone submitting to boost doesn't complain about having to learn a
non-standard build system that isn't documented richly enough to write
scripts from scratch.  These are not new problems.  I am *really* glad
that SC did something because in my mind it means boost won't die a
slow death to just posting independent libs on github.

On Wed, Jul 26, 2017 at 1:33 PM, Robert via Boost <boost_at_[hidden]> wrote:
> On 7/19/2017 11:08 AM, Klemens Morgenstern via Boost wrote:
>>
>> Am 18.07.2017 um 15:12 schrieb Jon Kalb via Boost:
>>>
>>> The libraries produced by the Boost community have had a greater impact
>>> on the way that the C++ community writes code than any other library
>>> implementation. The focus of the Boost community will always be on the
>>> libraries, but it is undeniable that we are dependent on and often limited
>>> by the infrastructure of our trade. Years ago, the move to Git was
>>> contentious; yet, it was required to improve development. In a similar vein
>>> our build system has become an impediment for many developers and users,
>>> existing and prospective.
>>>
>>>
>>> Therefore, we, the Steering Committee, announce to the Boost community
>>> our desire and intent to move Boost’s build system to CMake for users and
>>> developers alike. We are soliciting comments and proposals from the
>>> community to guide the process and the goals. Our desire is that the
>>> community can come to consensus by the end of the calendar year with a
>>> vision of supporting users and developers.
>>>
>>>
>>> We understand that the actual process of achieving the end goal will be
>>> long, time consuming, and not without its share of conflict. We also
>>> recognize that the Boost community is comprised of bright and passionate
>>> individuals that are eager to get involved and help get work done.
>>>
>>>
>>> The members of the Steering Committee have been encouraged by the
>>> discussions and activity surrounding CMake on the mailing lists over the
>>> years and know that many people have voiced visions. We hope that each of
>>> you rejoins the discussion to support this initiative and contributes to the
>>> common goal of improving Boost’s integration into the broader C++ ecosystem.
>>>
>>
>> Preface: I'm on team boost.build.
>>
>> We had long discussions about the whole CMake vs boost.build thing and I
>> will not reiterate those. I do think that boost.build is superior, but I
>> might be wrong about that.
>>
>> I am however quite certain that the style of just announcing that this
>> will happen is low. First of all, the discussion were not a stalemate, but
>> rather open. Last year, there was an effort put in to explore the
>> possibilities of boost.build v3; in the same way it would just be work to
>> setup a cmake build for boost. As a matter of fact Paul Fultz II is working
>> on that (https://github.com/pfultz2/boost-cmake)
>> So this discussion was far from over and the proof that CMake would be
>> superiour is lacking. So announcing the intention now by the steering
>> comittee (instead of announcing the intention to build an example with
>> Cmake) is premature; we have not only years of experience with boost.build
>> but also the people who developed it. Well had, anyway.
>> So prematurely declaring that boost will be going CMake without any
>> technical proof is just bad. And given the amount of CMake proponents we
>> have on this list: why isn't there a full boost CMake script yet? Why was
>> there more effort put into maintaining boost.build than CMake? Seems to me,
>> that the work put in should be of more importance, than the preferences
>> stated on the mailing lists.
>>
>> Secondly there has never been a discussion whether another build system
>> (or a fork thereof) might be better that CMake and boost.build (e.g. blaze,
>> qbs, meson, scons). So how can the intention be to use CMake?
>>
>> Thirdly, the "it's like moving to git" is just an awful comparison.
>> Boost.build was specifically build for boost and the superiority of git was
>> way more clear than for CMake. For one: git can handle svn repositories. If
>> CMake can build Jam-Files I'll be the first one to support it.
>>
>> 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.
>>
>> Considering that your job is to do what's best for boost, you might want
>> to reevaluate the way you operate. Losing Rene is surely not what is best
>> for boost.
>> The right way to do it, would've have been to setup a task force to
>> evaluate the use of CMake. Announcing like that makes me wonder how profound
>> the reasons for your decision actually are.
>>
>>
> I agree with all your points.  Thank you very much.  I have professional
> concerns on how the SC is operating.  I am confident many others do too.
> Here is an executive summary:
>
> Boost library use is recently incorporated here at my employer.  I have been
> successfully building every Boost release since 1.55 for both Intel and
> Visual Studio on Windows. The Cmake announcement method affects how and
> whether my employer will continue to use Boost libraries.  Has the SC given
> any thought of how an extreme announcement, lacking technical factual
> consensus, affects every single user, developer, software engineer, software
> architect, principal software engineer, project manager, technical lead,
> software engineering manager, product managers, etc.?  The Boost library
> list itself is proof that thorough design and architecture discussions occur
> on everything prior to inclusion.  Then, if it is approved by the C++
> Standards Committee, a library could become part of the official standard!
> The Cmake announcement is totally contrary to the established review
> process, as well as the page that summarizes all of the labor hours and
> source code lines that constitute Boost.  For reference, see this URL by
> Rene Rivera: http://www.boost.org/development/index.html.
>
> Thank you for your time,
>
> Robert
>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost