"Lars J. Aas" wrote:
>
> On Thu, Jan 11, 2001 at 10:37:01AM -0800, Wan-Teh Chang wrote:
> : I am trying to use autoconf on Windows with the
> : MKS Toolkit, which consists of a Korn shell and
> : the usual Unix utilities.
>
> Woopie doo, yet another Windows environment :)
Well, isn't this exactly what autoconf is for? :)
In fact, MKS Toolkit is quite popular. The "official"
Services for Unix (http://www.microsoft.com/windows2000/sfu/)
from Microsoft is based on MKS Toolkit. I guess the
reason config.guess and config.sub don't recognize MKS
right now is that it is not free of charge like Cygwin
and U/Win are.
The Windows port of GNU make also supports MKS Toolkit.
> [...]
> : Now the fun part. AC_PROG_CC fails for me for
> : two reasons:
> : 1. It tries to find the program 'cl' on the PATH.
> : However, the MKS shell takes the specified
> : pathname literally and does not automatically
> : append the .exe suffix. I found that if I
> : manually modify the configure script to use
> : 'cl.exe', then it works.
>
> The Windows port of the Korn shell is the part that ought
> to handle this detail IMO.
The command that's causing trouble is the 'test -f pathname'
command. Since you can have both 'foo' and 'foo.exe' in
the same directory, it's not clear whether 'test -f foo'
should only test for the existence of 'foo' or it should
also consider 'foo.bat', 'foo.exe', etc. (appending the
suffixes listed in the PATHEXT environment variable).
> : Can AC_PROG_CC be modified to look for 'cl.exe'
> : instead of 'cl' on Windows? I think that both
> : Cygwin and U/WIN should be able to handle 'cl.exe'.
>
> That would be a poor fix (you would for instance not be able to
> envelope cl.exe with a bat-file if you lock the extension to .exe).
Good point.
> A better fix would be to have AC_PATH_PROG (or whichever macro it
> is that searches for the compiler) to also consider implied exe-
> extensions on systems that use them, and add the extension to the
> returned program name.
Agreed. How do I submit this feature request?
Wan-Teh
