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.
It's this claim that has taken the actual community hostage, as it requires either a buy-in from everyone (not going to happen),
If people don't agree to switch then the transition is not going to happen. Either that or those people will follow Rene's example.
That's the problem. Some people are frustrated if they have to move, other are frustrated if they have to stay. Thus an "either or" scenario can't be the answer.
or some higher power to impose the change (which likewise isn't going to work out in the long term, even if it might initially look like progress).
Right.
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
Not sure what you have in mind with "half-baked support for CMake".
It means with CMake transition unfinished. Not all libraries converted, non-functional build/test/docs with CMake, etc.
But if some projects complete the transition, there isn't anything "unfinished", at least not if the infrastructure is set up to support this. It's what's called incremental progress. To paraphrase: it's better to have x% of the libraries converted 100% than 100% of the libraries converted x%.
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'll paraphrase my point, in case if I failed to communicate. Basically, a Boost maintainer has the following options:
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.
Again, not sure what your point is in listing these options. To me it seems clear that the SC is asking us to pick between 0. and 1., while I propose 3.
There's nothing disrespectful in this approach. It would be disrespectful if the SC or someone with universal commit permissions imposed CMake on everyone. Which is why the latest announcement from the SC is a big mistake, to put it mildly.
Oh, so we actually agree - or almost. :-) It seems the main difference is that you think the burden is the required work to switch, while to me it's the maintenance work after the switch.
Both are, and both require volunteers.
So ? Stefan -- ...ich hab' noch einen Koffer in Berlin...