> > CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons.
> Is this relevant though?
For this project and its day-to-day maintenance, unequivocally.
One of Richard's philosophies is "freedom means being able to take care of yourself," and that philosophy permeates all of his software projects, which eschew external dependencies because every single one reduces the project's level of freedom. Every time a third-party tool breaks, or introduces new, incompatible behavior as part of an upgrade, dependents of that tool suffer[^1]. All of Richard's projects have a strong culture of avoiding that suffering by avoiding third-party dependencies where at all possible, to the point of sometimes reinventing the wheel to extreme degrees (like implementing his own SCM).
That aspect aside, nobody in the SQLite project uses CMake, so it would never occur to us to migrate the build process to it. We write our own makefiles by hand _and we like it that way_. (Sidebar: Autosetup neither writes our makefiles nor introduces new syntax for doing so, in contrast to CMake.)
> I mean, there is no wrong in just coming forward and stating that you're already using a build system in another project and you're hoping to lower maintenance costs by standardizing on a single build system that you're already using. All other arguments sound dubious at best.
This isn't about standardizing on one build process, but about simplifying the lives of the developers and future maintenance of the project. We can't do that by porting to tools we don't otherwise use. If we weren't using Autosetup in other trees, and weren't happy with it, we wouldn't have even considered undertaking this effort and facing the downstream upheaval it will undoubtedly cause. We know, however, from 13 years of experience with it, that this tool does what we want, is low friction, and causes us an amount of grief which closely approaches zero[^2]. Without our collective background with Autosetup, we wouldn't have even considered porting away from the Autotools because that would be a case of "out of the frying pan and into the oven."
[^1]: As a concrete example: the SQLite project's WASM build is 100% dependent on the Emscripten toolchain for the simple reason that there is no feasible alternative. A handful of times over the past two years we have had to accommodate incompatible changes when upgrading Emscripten. That's hassle nobody wants. Obviously, software has to evolve, but being able to embed our build tools (Autosetup) directly in the source tree gives us control over the pace of that evolution. No system-wide upgrade is going to pull it out from under us, nor will it behave differently on downstream folks' machines.
[^2]: You won't ever hear me say that _any_ software is 100% grief-free, but autosetup is as close to it as, e.g., the bash shell.