On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
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.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch. Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later). I'm merely pointing out that rather then switching from Boost.Build to CMake atomically, we should attempt to do this piece-wise (and allow projects to keep the current logic if they prefer), which means supporting *two* build systems, not "a dozen". I'm really trying hard to come up with *practical* proposals to get out of the current stalemate. But replies like the above don't help at all.
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.
So you think we can't transition one library at a time, but you believe it will be possible to do a switch for 100+ libraries synchronously ? Sorry, but I can't follow your reasoning... Stefan -- ...ich hab' noch einen Koffer in Berlin...