On some platforms, such as Windows, executables are expected to have an
extension such as .exe. On these platforms, some compilers (GCC
among them) will automatically generate foo.exe when asked to
generate foo.
Automake provides mostly-transparent support for this. Unfortunately mostly doesn't yet mean fully. Until the English dictionary is revised, you will have to assist Automake if your package must support those platforms.
One thing you must be aware of is that, internally, Automake rewrites something like this:
bin_PROGRAMS = liver
to this:
bin_PROGRAMS = liver$(EXEEXT)
The targets Automake generates are likewise given the $(EXEEXT)
extension. EXEEXT
However, Automake cannot apply this rewriting to configure
substitutions. This means that if you are conditionally building a
program using such a substitution, then your configure.in must
take care to add $(EXEEXT) when constructing the output variable.
With Autoconf 2.13 and earlier, you must explicitly use AC_EXEEXT
to get this support. With Autoconf 2.50, AC_EXEEXT is run
automatically if you configure a compiler (say, through
AC_PROG_CC).
Sometimes maintainers like to write an explicit link rule for their
program. Without executable extension support, this is easy--you
simply write a target with the same name as the program. However, when
executable extension support is enabled, you must instead add the
$(EXEEXT) suffix.
Unfortunately, due to the change in Autoconf 2.50, this means you must
always add this extension. However, this is a problem for maintainers
who know their package will never run on a platform that has executable
extensions. For those maintainers, the no-exeext option
(see Options) will disable this feature. This works in a fairly
ugly way; if no-exeext is seen, then the presence of a target
named foo in Makefile.am will override an
automake-generated target of the form foo$(EXEEXT). Without the
no-exeext option, this use will give an error.