Unfortunately most of his "rant" is justified. Autotools are exceptionally bad for several reasons: - They are difficult and not at all intuitive to learn and

Unfortunately most of his "rant" is justified. Autotools are exceptionally bad for several reasons: - They are difficult and not at all intuitive to learn and use. As another poster noted, there are no abstractions whatsoever, so what's stopping me from just writing a shell script that will check for the location of libparadise v3.1.6? This may be a subjective issue, so please check out gtkpod's CMakeLists.txt and configure.in and tell me with a straight face that you'd pick autotools. - They are well-documented and easily extendable...Oops, no they're not! - They aren't backward or forward compatible, and almost every other major version has serious regressions. This is a big whoop if you claim to want to produce portable software. - Configuration is scattered around the build tree instead of one file. Seriously, I don't need this. I have enough of an issue with my current project's 400+ modules, thank you very much. - Slow. They're beautified shell scripts, after all. But also, they check for unneeded dependencies and antiquated features (checking for an ANSI-C conforming const...OK). - And last but not least, its "caching" is the most braindead half-implemented feature I've ever encountered since 1984. It's literally cost me hours to discover problems caused by caching the config files. On the other hand, there aren't any better alternatives, so I'll just go cry for a bit.