Oh, absolutely, python is a nonstarter for an autotools replacement. Autotools is/was great because it worked everywhere, even during early bootstrap where all you have is shell, basic shell utilities, and a C compiler. Python doesn't, and never will. The C ports of meson and ninja could potentially be part of a future, modernized, bootstrap-the-world effort. Switching build systems is crazy hard, so you want to take advantage of what people are already moving to. My impression is that meson is gaining momentum. In 2020, I spent some time porting zlib-ng's build system to meson. That was fun. But rather than submit that port, I spent my time setting up a script to run at CI time that verified their Make and CMake builds produce bit-for-bit identical outputs. That's still in use, and makes it a *lot* easier for them to support both build systems. I figured having a verifier like that would make it easier to add Meson support later, should someone want to do it. And I recommend doing that when adding a new build system to any core tool. It's not common practice, but it's not that hard, especially if you have an example to work from. - Dan On Tue, Feb 15, 2022 at 7:52 PM Mike Frysinger <vapier@xxxxxxxxxx> wrote: > > On 15 Feb 2022 20:25, Jacob Bachmeyer wrote: > > Dan Kegel wrote: > > > Meson is a candidate for such a next-gen config system. It is in python, > > > which does not quite qualify as usable during early uplift/bootstrap, but > > > there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/ > > > > *Please* do not introduce a dependency on Python; they do not worry much > > about backwards compatibility. If there is ever a Python 4 with a 3->4 > > transition anything like the 2->3 transition, you could end up with > > every past release relying on current Python becoming unbuildable. > > Python 3.0 isn't even compatible with Python 3.10 in some ways. it's a > sliding window of time/releases, not a major version skew. > > > Having complex dependencies for creating the build scripts is one thing, > > but needing major packages (like Python) to *use* the build scripts is a > > serious problem for anything below the "user application" tier, > > especially the "base system" tier. > > yeah, i see no path forward for requiring Python in the generated configure > or Makefile.in files. i wouldn't feel as bad about replacing the current > perl code with python to run `automake`, but i don't think the current set > of Automake maintainers would agree :). > -mike
