First, the AC_CONFIG_HEADER construct.
Some macro extensions to the default Automake/Autoconf constructs uses the old AC_CONFIG_HEADER construct which has been superseded by AC_CONFIG_HEADERS in recent GNU autotools (in my case I'm using automake 1.10). Notice the change to plural form with addition of "S" in the end of the macro.
One particular annoying bug that I found is the widely used AX_PREFIX_CONFIG_H macro uses AC_CONFIG_HEADER in its older version (which is used in a lot of opensource project). Therefore, if you're migrating an old source code which uses this particular macro in its older incarnation, make sure you change the AC_CONFIG_HEADER macro to AC_CONFIG_HEADERS. Otherwise, automake will fail when you try to update the auto-generated Makefiles and the corresponding build scripts.
Second, the use of GNU make extension
Sometimes using GNU make extensions in Makefile.am file will cause portability warnings to be shown when you invoke automake. To prevent the warning those warnings, you can use the following construct:
AM_INIT_AUTOMAKE([-Wno-portability])
in your configure.ac/configure.in file.
Those are the most important things. Another rather important thing is updating the libtool-related scripts if the opensource source code uses libtool and you're actually migrating to newer autotools version from a very old one. It's as easy as invoking this:
me@my_machine:~/Projects$ libtoolize -c
The "-c" switch instructs libtool to copy the libtool-related scripts instead of symlinking them. It's important to do so, to make sure the old libtool-related scripts updated accordingly and the new one will be included in the software package. This is especially important if you use some sort of Revision Control System (RCS) such as subversion, git or others.
That's it for now.
