7.17 Support for executable extensions

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.

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.

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 rule whose target is the name of 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 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.