Initially intended as a Napster/OpenNap 'robot,' AutoNap can be used like any other console napster client. It retrievs a list of running servers automatically. Beside the interactive-mode there is also the non-interactive mode which is useful for letting AutoNap run overnight or as a cron-job.
I am sorry.
While this may sound like a good idea, it is hardly practical for the maintainer of the software. This sounds dreadful:
Typically, you'll want to provide multiple versions of your software, and for multiple platforms.
In the worst case, this will require access to these different platforms (just think of the typical endianess problem which is usually resolved at compile-time).
That just had to be said
I can vigorously agree with most that was said in this article.
autoconf is not so much a problem for the end-user (as long as it works which happens to be the case most of the time). But indeed I once tried to use it as a developer and frankly, I gave up after a while. The documentation I found on the internet was ludicrous and - just as described in the text - outdated. I found several scattered documents that contradicted each other severely: Each had a different opinion in which sequence I should run the various auto* tools. (needless to mention: none of the suggested orders worked).
I do prefer those projects using it, though. The usual steps of "./configure --help; ./configure --args=...; make; make install" is familiar and convenient. But now I understand why so many projects (X, exim, Perl partly to name just a few) are gradually leaving this well-beaten track and use their own (or some other) installation frameworks.