-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld via Boost Sent: Wednesday, February 21, 2018 1:38 AM

On 20.02.2018 19:26, Louis Dionne via Boost wrote:

...

if library authors don't want to spend time adding CMake support themselves, it should be possible to just copy the files in [2] for their library. Paul, you can correct me if anything here is incorrect.

[1]: https://github.com/boost-cmake/bcm [2]: https://github.com/boost-cmake/boost

At the risk of repeating myself: you present too simplistic a picture. It sounds as if library authors either are willing to do the transition themselves, or are happy to accept someone else writing some files that they can then "just copy". The OP however asked about "support", which is far more than adding some CMake files to their respective repos. It includes helping users who run into (build) issues compiling their library. And I still don't see where that support is going to come from.

Actually, I'd personally be quite happy with just some basic cmake files, as long as there is a common structure behind them, they are properly integrated with the main project and they make boost libraries accessible via find_package. Thing is: With cmake, I can usually fix most problems myself because I use it everyday in other projects. With boost build I can't (not that I had any problems so far). But admittedly, once cmake becomes the official build system for boost, some level of support probably has to be provided (whatever support means in that context).

On Feb 20, 2018, at 6:26 PM, Louis Dionne via Boost wrote:

On Tue, Feb 20, 2018 at 12:18 AM, Mike via Boost wrote:

...

Hi everyone, since I couldn't find any official information about that, I wanted to ask if there is any new information about the cmake support in boost (since the initial discussion on the ml after the steering committee's announcement)?

Is there some agreement on how to do the transition or at least a

...

popular formal/informal proposal?

As far as I can tell, the current status is that we're waiting for a formal review of Paul Fultz's BCM library [1] to happen, which is currently blocked on getting a review manager. The goal of BCM is to provide a few CMake utilities to make it easier for Boost libraries to implement support for CMake in a consistent manner. If BCM is seen as the proper way to do CMake within Boost, I guess the logical next step would be to start using BCM to add CMake support in the libraries. Unless I'm mistaken, Paul has already basically done this for all libraries [2]; if library authors don't want to spend time adding CMake support themselves, it should be possible to just copy the files in [2] for their library. Paul, you can correct me if anything here is incorrect.

That is correct. I have built a collection cmake modules to aid in building cmake scripts. We are looking for a review manager for this, as the original manager will not be able to. In the mean time, I have done an initial implementation of cmake across boost, as a proof-of-concept. After the cmake modules are accepted in boost, the goal would be to integrate these initial cmake files across boost after author’s modifications. Thanks, Paul

On 2/23/18 2:35 AM, Hans Dembinski via Boost wrote:

Hi Paul,

...

On 21. Feb 2018, at 03:42, P F via Boost wrote:

That is correct. I have built a collection cmake modules to aid in building cmake scripts. We are looking for a review manager for this, as the original manager will not be able to. In the mean time, I have done an initial implementation of cmake across boost, as a proof-of-concept. After the cmake modules are accepted in boost, the goal would be to integrate these initial cmake files across boost after author’s modifications.

I would be happy to fill the role of review manager for BCM, although I am not sure if I fulfil the criterion of an "active boost member" already http://www.boost.org/community/reviews.html#Review_Manager

If that refers to someone who maintains a library in boost, I do not pass. If it includes someone who has been around for a while, participated in discussions, submitted a patch to boost (I admit, it was a really small one), and has a proposed library in the review queue, then I could do it.

Personally, I'm thinking an active boost member is someone who has spent significant time interacting on the mailing lists and whose posts demonstrate the appropriate temperament, detachment, maturity, C++ and other technical competence. I'm no sure how to assess though. My only idea would be for those who have some opinion and/or knowledge on the potential reviewer to send a private email to ron garcia - our long time, well respected review wizard who schedules the reviews. In general, I would like to encourage wider participation in boost by those who may not be able to justify the commitment that making a library requires. An example of a "good thing" is the github PR system which has permited many more people to make small but very valuable contributions.

Best regards, Hans

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Robert,

On 23. Feb 2018, at 17:43, Robert Ramey via Boost wrote:

Personally, I'm thinking an active boost member is someone who has spent significant time interacting on the mailing lists and whose posts demonstrate the appropriate temperament, detachment, maturity, C++ and other technical competence.

I am glad to hear that you see it this way. Let me mention a few things in my favour, then. I think I am reasonably knowledgable in the domain of build systems. I have >5 years of hacking experience with CMake in two large projects and many small ones. CMake is my build system of choice, but I also tinkered with pure Makefiles, QMake, SCons, and B2. I keep up with the evolution of best practices in CMake. My own CMakeLists.txt files lack the elegance that BCM displays, but I never tried to make a clean CMake module library. Regarding soft skills, I consider myself quite good at evaluating arguments and taking a neutral stance. I don't value my own opinion above others, the ultimate arbiter for me on any topic is whether something makes sense or not. If someone else with more experience steps forward that is fine with me as well, but my offer stands. Best regards, Hans

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of P F via Boost Sent: Wednesday, February 21, 2018 3:42 AM

...

On Feb 20, 2018, at 6:26 PM, Louis Dionne via Boost wrote:

On Tue, Feb 20, 2018 at 12:18 AM, Mike via Boost wrote:

...

Hi everyone, since I couldn't find any official information about that, I wanted to ask if there is any new information about the cmake support in boost (since the initial discussion on the ml after the steering committee's announcement)?

Is there some agreement on how to do the transition or at least a

...

popular formal/informal proposal?

As far as I can tell, the current status is that we're waiting for a formal review of Paul Fultz's BCM library [1] to happen, which is currently blocked on getting a review manager. The goal of BCM is to provide a few CMake utilities to make it easier for Boost libraries to implement support for CMake in a consistent manner. If BCM is seen as the proper way to do CMake within Boost, I guess the logical next step would be to start using BCM to add CMake support in the libraries. Unless I'm mistaken, Paul has already basically done this for all libraries [2]; if library authors don't want to spend time adding CMake support themselves, it should be possible to just copy the files in [2] for their library. Paul, you can correct me if anything here is incorrect.

That is correct. I have built a collection cmake modules to aid in building cmake scripts. We are looking for a review manager for this, as the original manager will not be able to. In the mean time, I have done an initial implementation of cmake across boost, as a proof-of-concept. After the cmake modules are accepted in boost, the goal would be to integrate these initial cmake files across boost after author’s modifications.

Thanks, Paul

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thank you both for the update and explanation. I hope you find a review manager soon. And I hope the lib doesn't get rejected just because some authors want to block transition to cmake altogether. Best Mike

On 2/23/18 3:53 PM, mike via Boost wrote:

Thank you both for the update and explanation. I hope you find a review manager soon. And I hope the lib doesn't get rejected just because some authors want to block transition to cmake altogether.

It will also ensure that everyone gets a say. Hopefully the employment of the review processes will result in general acceptance of the result/decision regardless of what it turns out to be. Robert Ramey

Best Mike

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 2/24/18 2:41 PM, Stefan Seefeld via Boost wrote:

As one of the more vocal opponents to the announced "move", allow me to comment.

I think there is a real danger that two distinct questions get conflated:

a) a technical review of infrastructure to build Boost libraries with CMake.

b) whether and how individual library developers / maintainers can be mandated to use any particular tooling (be it to build, to document, to bug-track, etc., etc.)

It's true, a successful completion of a) makes it more likely for the code to be accepted by the community. But neither should a positive review result in a mandatory use by all libraries, nor should a review be biased based on the perceived danger of having to migrate if the review is completed successfully.

Right now my only focus is to get a fair and complete evaluation the only serious candidate for a CMake build system. Other considerations/decisions can be deferred until we past this hurdle. Robert Ramey