> > > Until now this package's configure.in has been using AC_EXEEXT alone
> > > (w/o AC_PROG_CC), now I seem to need adding AC_PROG_CC, but ..
> > > .. Adding AC_CANONICAL_HOST would give sense, but this also
> > > apparently isn't sufficient.
> >
> > This does seem like the right thing to do though, as here the .exe is
> > not an important part of setting up compilation rules, but rather
> > something specific to the platform.
> >
>
> Fully agreed, wrt. this particular case.
>
> But it's rather easy to construct nasty examples, e.g.:
>
> Building executables for platforms requireing an *.exe suffix with
> tools autoconf and automake do not support directly.
That merely indicates an area that needs work, not a particular problem
with AC_EXEEXT. I don't see a clean way to deduce an executable extension
other than a) using what the compiler uses (i.e. the current way) or b)
deducing it from the system (as sort-of done before, and previously
suggested for cases like these).
As such, perhaps the optimal expansion of AC_EXEEXT would be:
nothing, if AC_PROG_CC is used somewhere, or the snippet I posted
(using AC_CANONICAL_*) if it isn't. Perhaps we may also want several
incarnations of this macro, as we may need to know the executable
extension for more than one environment (i.e. both host and target).
