| My entire build can run in less time than a ./configure script. It doesn't require developers to run ./autogen.sh, or to have autotools installed (in their correct versions). It doesn't contain obscene amounts of indirection, where the actual libraries live in a hidden directory called .libs (looking at you, libtool). It doesn't make you write m4, or Makefile.am files with all these magic incantations. It doesn't make you delve into the guts of these crufty systems when things don't work the way you expect. If you want build systems to satisfy your use cases, publish some doc of best practices and capabilities that all build system interfaces should provide. If I'm convinced I'll be happy to conform to the interface you need. But there is no way you're going to convince me that everyone needs to just keep using autotools (a specific implementation) forever. I hate them. I mean, by that logic, why are you doing something new like GNU Guix when everybody already knows/uses APT, RPM, BSD ports, etc? "Just learn [them], get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD." Or maybe it is worth breaking with the past sometimes, when you think you can do better. |
All of the things you list are annoyances with crud that exists to satisfy this or that use-case which I suppose you personally don't need, which doesn't mean they don't have purposes. I would also say they are all minor annoyances. Your builds run faster than a ./configure script? Not building particularly large projects I suppose. Installing autotools? Big deal! I don't know when one needs to write m4, but the Makefile.am format looks rather clean and minimal to me; I don't see how you could have something much cleaner without losing a lot of generality. And having to delve into the guts of some obscure system is exactly what I had to do a few times because some piece of software refuses to keep with the convention and just use Autotools.
The documentation you ask for is idealistic and unrealistic. GNU Autotools are free software, and with decades-old proven maturity; I see no reason not to use them. The only pseudo-reasons I see are NIH, FUD, etc.; the usual.
GNU Guix (and before that, Nix) is fundamentally different from all other package managers, so that analogy makes no sense here unless you have some radically different innovative build system.