unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).
I would oppose this PR for the following reasons: 1. A lot of work has been invested by many people in the Boost cmake implementation, which is ready for peer review. It would do its authors a great disservice to push through some stop gap. Instead, the OP should consider review managing the Boost cmake implementation if he is so keen on this. That's the blocker - lack of review manager. Not that the work hasn't been done. 2. cmake is a big move for Boost. Submitting a stopgap without proper community review is not in keeping with Boost's established precedent and norms. 3. It is the wrong stopgap solution at a technical level. The correct stopgap solution is an imported targets cmake file which refers to the build outputs generated by Boost.Build. Possibly, Boost.Build should generate it, but I can see worth in a Python script which can take a release distro and generate from that an imported targets cmake. Even better if said Python script can be run as part of release management, and the imported targets cmake file gets shipped with the release distro. I applaud the OP's eagerness. But he's proposing the wrong solution, and for the wrong reasons. Niall