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.
The variables TESTS and XFAIL_TESTS (see Simple Tests)
are also rewritten if they contain filenames that have been declared as
programs in the same Makefile. (This is mostly useful when some
programs from check_PROGRAMS are listed in TESTS.)
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.ac must
take care to add ‘$(EXEEXT)’ when constructing the output variable.
Sometimes maintainers like to write an explicit link rule for their program. Without executable extension support, this is easy—you simply write a rule whose target is the name of the program. However, when executable extension support is enabled, you must instead add the ‘$(EXEEXT)’ suffix.
This might be a nuisance for maintainers who know their package will
never run on a platform that has
executable extensions. For those maintainers, the no-exeext
option (see Changing Automake’s Behavior) will disable this feature. This works in a
fairly ugly way; if no-exeext is seen, then the presence of a
rule for a target named foo in Makefile.am will override
an automake-generated rule for ‘foo$(EXEEXT)’. Without
the no-exeext option, this use will give a diagnostic.