On 07/21/17 18:57, Stefan Seefeld via Boost wrote:
Here is (once again) how I would approach this instead:
* Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals). * Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic. * With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities.
Does this process appeal to anyone ?
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used. Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.