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
bin_PROGRAMS = liver$(EXEEXT)
The targets Automake generates are likewise given the ‘$(EXEEXT)’ extension.
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
check_PROGRAMS are listed in
However, Automake cannot apply this rewriting to
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
automake-generated rule for ‘foo$(EXEEXT)’. Without
the no-exeext option, this use will give a diagnostic.