Paolo Bonzini wrote: > >> AFAIK it has been introduced and is used by users as workaround >> (e.g., by setting it in config.site). So if we can agree to it, >> we should probably document it rather than zapping it. >> >> See for example <http://www.cygwin.com/ml/cygwin/2005-01/msg01220.html>. > > Or we could steal code to set it appropriately from gcc's config.build > file. > > case $build in > alpha*-dec-*vms* | \ > i[34567]86-*-cygwin* | i[34567]86-*-pe | \ > i[34567]86-*-mingw32* | \ > i[34567]86-pc-msdosdjgpp* | \ > i[34567]86-*-uwin* | \ > ac_executable_extensions=${ac_executable_extensions-'.exe'} > ;; > esac This may have to be updated for x64/ia64 processors as well, unless they also use the iX86 prefix; other than that this seems ok. Note that I think that back when I worked on the DJGPP port of autoconf, I set some additional extensions (.com, .bat, .pl, .sh, perhaps others) in my config.site (probably the same set supported by DJGPP's system()), so if it's to be replaced by a fixed list without config.site overrides, we'd have to make sure the set is the most appropriate one. Also, under Windows, there's an envvar ($PATHEXT, semicolon-separated) that can be used to define executable extensions for the cmd.exe shell, so that could perhaps be used as well. I'm personally in favor of simply documenting it, because maintaining the appropriate set could be a real pain. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
