Re: PATCH: Cygwin - second go.

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Aug 15, 10:15am, Andrej Borsenkow wrote:
} Subject: RE: PATCH: Cygwin - second go.
}
} > I just noticed, however that under autoconf 2.13 the definion of AC_CYGWIN
} > doesn't work right if you follow it with a `dnl' directive.  It ends up
} > merging with the expansion of AC_EXEEXT that follows it, so a configure
} > script generated from autoconf 2.13 won't ever set CYGWIN=yes properly.
} >
} > The solution is either to remove the `dnl' comment from the line with
} > the AC_CYGWIN call, or simply to put a blank line after it, which is
} > what I did.
} 
} Are you sure, it is a problem of missing empty line?

Yes.

} Look, what is generated:
} 
} CYGWIN=
} test "$ac_cv_cygwin" = yes && CYGWIN=yes                   echo $ac_n
} "checking for mingw32 environment""... $ac_c" 1>&6
} 
} that is, CYGWIN is set in environment of `echo' command and lost after this.

Right.

} This expansion is part of AC_CYGWIN and has nothing to do with AC_EXEEXT.

Wrong.  In /usr/lib/autoconf/acspecific.m4 we have:

AC_DEFUN(AC_EXEEXT,
[AC_REQUIRE([AC_CYGWIN])
AC_REQUIRE([AC_MINGW32])
AC_MSG_CHECKING([for executable suffix])
....

The `test "$ac_cv_cygwin" = yes && CYGWIN=yes' comes from AC_CYGWIN and
the `echo $ac_n "checking for mingw32 environment""... $ac_c" 1>&6' is
from AC_MINGW32.  The problem is that if you *explicitly* use AC_CYGWIN,
then the first AC_REQUIRE in AC_EXEEXT doesn't expand and the beginning
of AC_MINGW32 gets pasted onto the end of the explicit AC_CYGWIN output.

So maybe the bug you're thinking of is that AC_EXEEXT gets it wrong if
you *don't* explicitly use AC_CYGWIN followed by a blank line; I didn't
try that, but I *did* check the output the way I committed the patch.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net