$ tar xf autotools-using-package.tar.bz2
$ cd autotools-using-package
Error: possibly undefined macro AC_BLABLABA
checking for build system type...
$ make clean
$ make distclean
$ ./configure --prefix=$HOME/my_app ...
$ make -j9 install
install: no such file or directory blabla.la
$ make install
Let's submit this fix upstream. No problem, use diff.
$ mkdir temp
$ tar xf autotools-using-package.tar.bz2 -C temp
$ mv temp/autotools-using-package autotools-using-package.orig
$ diff -urN autotools-using-package.orig autotools-using-package
I know you're going to say I should be using the VCS checkout in the first place, which would hopefully be configured to ignore the autogenerated files. But as a user, or distribution maintainer, most of the time the bug you find is with a specific, packaged version of the software, and it may be quite an effort to figure out how to get the exact same version from the VCS server.
I always run "./autogen.sh --help" for exactly that reason; then if I see --help output from configure, I know that autogen.sh "helpfully" ran configure for me.
You can also usually just run "autoreconf -v -f -i" directly, unless the package has done something unusual that it needs to take extra steps in autogen for.
Also, autotools amazing features aren't all that. Builds out of the source dir? Eh.. This is 2012 and it doesn't impress anymore. Both waf and SCons can do it no problem. Autotools-projects, on the other hand, seem to always put the object files and linked library in the source directory. Sometimes the built library is put in a hidden directory for some reason I don't understand. Possibly it has something to do with libtool, another kludge on top of autotools one rather would do without. Since modern build tools does not pollute the source directories you basically get make distcheck for free. Waf has it builtin for example and it can easily be extended to also upload your tarballs to your distribution server, sending annoncement emails and what have you.
For a "real" project, https://github.com/ggreer/the_silver_searcher, I have the same set-up: Makefile.am and configure.ac with no generated code in the repo. It works fine as long as you have pkg-config, and most people do. It builds and runs on Solaris, OS X, FreeBSD, and any Linux distro you like.
Although I use autotools the "right way", I'm not a fan of it at all. There are multiple levels of generated files. Configure is generated from configure.in which is generated from configure.ac. Makefile is generated from configure and Makefile.in. Makefile.in is generated from Makefile.am. There are other files in the mix as well. Config.h, config.h.in, aclocal.m4, and various symlinks to autotools (compile, depcomp, install-sh, and missing) get generated. It's insane.
There are other problems. Minor versions of autotools can behave completely differently. AM_SILENT_MAKE was removed between automake 1.10 and 1.11. Instead of printing out minimal text during a build, scripts using that macro crash. Another example: 1.9 requires AM_PROG_CC_C_O to compile anything useful but 1.10 doesn't. What's crazy is that 1.9 actually spits out an error message telling you to add AM_PROG_CC_C_O to your configure.ac. It makes no sense.
A system this complicated can't be pruned without breaking backwards compatibility. For autotools, that's not feasible. There are too many projects that would need to be fixed. The next-best solution is to use something else for new projects and let autotools fade gently into history.