Hello, Ben Pfaff reported that the following configure.ac > AC_PREREQ(2.50) > AC_INIT(test, 1.0) > AC_PROG_CC > AC_PROG_CXX > AC_OUTPUT with > CC=nonexistent ./configure fails, while > CXX=nonexistent ./configure surprisingly succeeds. And: > The situation is reversed if the AC_PROG_CC and AC_PROG_CXX lines > are correspondingly reversed in the configure.ac. Ben also analysed the bug and explained why this happens. Thanks! Ben, what would you say about an answer like this: The purpose of ./configure is to determine properties about the host system and build environment. It's primary purpose is not to do sanity checks. So the behaviour you report is not a bug as such, even though it looks weird. ./configure just does its job: in order to determine the exec extension of the system, it has to run the compiler of the current language. For the second languagem is supposes that the extension is the same. (The scenarion when the two language compilers use two different extensions for generated executable files, is not supported.) If ./configure stumbles over a serious problem, it bails out with an error message. But if the problem in not an obstacle for configure's work, ... Well, ./configure _could_ do more sanity checks, but the expense is obvious: all the people who pass correct parameters would have to wait another few seconds. Have a nice day, Stepan Kasal _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
