On 07/22/17 00:48, Stefan Seefeld via Boost wrote:
On 21.07.2017 17:35, Andrey Semashev via Boost wrote:
On 07/21/17 23:28, Stefan Seefeld via Boost wrote:
On 21.07.2017 16:15, Andrey Semashev via Boost wrote:
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
The allusion to things not going to work for Boost users, unless the entirety of Boost has migrated to CMake.
This is not what I was saying. I was saying that the model of each library using its own build system won't work well for users. But in this thread I'm not proposing each library to use "its own build system". I'm proposing to allow each library to choose whether to move to CMake or to stay with Boost.Build, as an attempt to unlock the current gridlock.
Right. For users, that would be somewhat better than everyone using their own build system, but the problems that I described in my original reply in this thread remain. Again, I think for many users half CMake-based half Boost.Build-based Boost distribution would be more difficult to use than just CMake-based or just Boost.Build-based distribution.
The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way.
Don't force anyone !
Not sure what you mean. Noone's forcing anyone. Well, except the SC after the announcement.
Huh, now it's me who isn't sure what you mean :-) Can you please rephrase this last set of sentences ? I'm not sure what you are trying to say here. :-)
I was coming from the premise of Boost migrating to CMake as a whole, which is what I think is being suggested by the SC. In this scenario, each maintainer has the options I listed below.
0. Actively help the transition and maintenance of CMake afterwards.
1. Accept the burden of maintaining CMake for his library. Depending on the migration plan and the final model, CMake may be the only build system to maintain or be an addition to Boost.Build.
2. Resign from maintenance.
3. Actively object migrating their particular library, leaving Boost multi-build-system.
4. Despite the SC the community decides not to switch to CMake and everything is kept as is.
Everyone are free to pick their poison.