can cmake supersede autotools piece by piece?

[Mario Emmenlauer <ma...@emmenlauer.de>]

Hi all!

I know this is not an easy discussion, but I have to raise the
question nonetheless :-(

I understand that the current policy is to keep the autotools build
100% intact and running until cmake is on par with autotools, and
only then deprecate it. Is that correct?

If so, I'd like to kindly ask if this policy may be changed. In my
personal opinion, it would be more sensible to allow breaking changes
to the autotools of a specific component whenever this component can
be fully built and tested with cmake. Or even simpler, as soon as a
component of Thrift can be fully build and tested from cmake, I would
drop the autotools support for this component.

With the current policy, its non-beneficial for a contributor to add
cmake support to any component, because they will have to maintain
cmake _and_ autotools support. This happened to me now multiple times.
Two of my pull requests are blocked because they build only with
cmake. Since nobody seems to volunteer to maintain autotools for pull
requests, this is effectively blocking progress.

I think for Thrift's needs of CI and testing, the new policy would
be good enough. Whenever cmake support for a component is ready,
this component can be built and tested from cmake.

The downside of the proposed policy is that it puts a higher burden
on users because they may need to use two build systems consecutively
to get all features of Thrift. But I'm under the impression that this
is an acceptable tradeoff for a significant simplification of Thrift
development and maintenance.

What do you think?

All the best,

    Mario