It's difficult because the API is m4-templated shell (configure.ac, macros) and makefiles, and so you can't easily handle any existing autoconf project without

It's difficult because the API is m4-templated shell (configure.ac, macros) and makefiles, and so you can't easily handle any existing autoconf project without using what is effectively an implementation of m4, shell, and make. Yes, projects themselves could move to something else, but there are many options for that (mentioned in the article). I'm not sure how much value an incompatible autotools-flavored tool would have to anyone. (If you're not templating shell, there are way better flavors of build tool, anyway.) This is, incidentally, a software design lesson: if your input space is too big and you basically encourage people to see straight through your abstractions, you have no abstractions. (I'm facing this at work: we have an intricate set of homegrown makefiles that evolved over some 15 years, and make is hard to teach and debug, but it's pretty difficult to switch to anything else because we allowed people to write custom makefile rules too and there are lots of them. We can automatically convert the easy cases, which are the majority, but then we'd have two systems, which is worse.)