9.15 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. 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 section 17. 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 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.