Personally, I welcome this move... Shayne -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jon Kalb via Boost-users Sent: Tuesday, July 18, 2017 7:12 AM To: Boost Users Cc: Jon Kalb Subject: [Non-DoD Source] [Boost-users] CMake Announcement from Boost Steering Committee 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. For the Boost Steering Committee, Jon Kalb, Chair jonkalb@boost.org

On 18/07/17 14:12, Jon Kalb via Boost-users wrote:

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.

This is great news to hear.

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.

I'm one of the maintainers of the CMake Boost support (https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake) Currently we hardcode all the inter-module library and header dependency information back to Boost 1.33 so that it's possible to call find_package(Boost COMPONENT filesystem thread) and have it find the libraries and tell CMake what the dependencies are so it can compile and link with the correct includes and libraries. With Boost using CMake itself, it would be nice if this information could be provided directly by Boost, so that the dependency information doesn't need to be hardcoded--it can be supplied directly with the build in the form of a ${libdir}/cmake/BoostConfig.cmake script. This would mean we could retire FindBoost.cmake and cease the hardcoding of dependency information for new releases from this point onward. We would need to keep it around for backward compatibility for some time, but users could switch over to the provided configuration pretty seamlessly. Over the years, FindBoost has accumulated a number of tweakable settings and variables and which report various information about Boost features (e.g. enabling autolinking). While some of these might no longer be needed, it would be nice if you could consider preserving the existing option and target names used in the above linked FindBoost.cmake script for backward compatibility so that users can switch to the new config script with ease. I'd be happy to work with you on making any needed changes to FindBoost.cmake for forward compatibility with exported Boost cmake configuration. Likewise I'd be happy to provide any assistance with CMake support in Boost itself, e.g. to get the configuration export working (if it's not been done already). Kind regards, Roger

I welcome this move. Congratulations!

We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict.

How will the migration work in practice?

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.

How can non-maintainers help? Do we just submit pull requests to the git repos? Finally, what will be the minimum CMake version? I humbly suggest something modern. Again, I want to express my respect for this move. It must have been a big decision. Raoul Wols