Re: The problem with autoconf...
On balance, it seems to me that most of the accusations levelled at autoconf here are more to do with how it's used than the software itself. It is a pretty horrendous bit of software in itself, thanks to the pretty steep learning curve, and I've been hit a few times by some of its idiosyncrasies (incompatible versions, missing m4 macros and the way it sometimes runs differently if you run 'sh ./configure' or './configure', mainly) but on the whole if you've got a project beyond a certain size and you care about portability, I think it's usually a no-brainer: use autoconf.
As I already said, the problem is often more to do with how the software is used. It's not a magic bullet that will automatically make your program portable. You still have to do all the work in your source code to account for all the different flavours of *nix or whatever, like whether they have certain library functions available to them (and which version), what system include files are needed, as well as, sometimes, lower level concerns like the machine's endianness, word sizes, data alignment characteristics, and especially the right architecture (or compiler)-specific flags to use. The other thing about autoconf, besides being an aid to achieving portability is that modern software generally has a multitude of dependencies, and without something like autoconf (and supporting tools/standards like pkg-config) any homebrew configure/make system is apt to get very complex very fast, and worse than that, they're (relatively speaking) very difficult to maintain and often not very portable in themselves. Most problems with building (besides problems with dependencies) tend to be with the author not writing portable code in the first place or simply not knowing about the foibles of your particular system or toolchain. Again, that's not autoconf's fault, but it is what it's designed to help the coder with.
and that's why I end up just using shell scripts for my projects.
There's nothing wrong with rolling your own configure/build system, but for the end user (ie, the person building the system), I think that familiarity with the autoconf system usually makes it easier to handle cases where things go wrong for some reason. Once you've compiled a few dozen apps it becomes pretty easy to figure out where the build is going wrong and how to fix it. Maybe that's just my personal preference, though.