Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Florent Castelli (florent.castelli_at_[hidden])
Date: 2017-07-19 16:32:24

On 19/07/2017 18:08, 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.

My knowledge of Boot Build is quite limited, but that of CMake is quite 
extensive and I believe that CMake is indeed a superior tool when 
correctly used. Unfortunately, there are lots of bad examples out there 
as well people keeping on using ancient versions of it that are quite 
limited, in a similar way as when you compare C++98 to C++17.

>
> 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.

There are several examples of CMake built Boost in the wild already and 
even some using Bazel or Buck. I've made one of them and it's used in 
millions of user installs and works quite well so far!
It's been open sourced here by the way: 
https://github.com/Orphis/boost-cmake .
It supports building the library and integration in any project using 
"add_subdirectory()" and will even build and run quite a lot of tests in 
the standalone version to ensure libraries are built correctly.
The target is users or the library, and they're happy with it since they 
don't have to deal with b2 and tons of prebuilt variants for their cross 
platform application. I started talking after the announcement to Paul 
Fultz II and others about contributing as well to target both users and 
Boost developers.
I'll admit that my project doesn't build Boost Python as no one asked 
for it, but that would be trivial to add.

>
> 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?

I believe CMake has integrations in quite a lot of major IDEs and a 
community much larger than any of the other tools. It's becoming 
standard and ubiquitous.

>
> 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.
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost