document a surprising behaviour of macros AC_PROG_{CC,CXX,F77}

[Stefano Lattarini]

Hello everybody.

I here repropose a simple patch to the autoconf manual, adding a 
description of a (IMHO) weird interaction between the AC_PROG_CC,
AC_PROG_CXX and AC_PROG_F77 macros.  It has to to do with the fact 
that, among this macros, only the first expanded one set $OBJEXT and
check for the possibility to really create executables, aborting 
configure if any of these fails.

This topic came up a while ago on bug-autoconf, but the patch I posted 
there went unnoticed or was ignored.  This list seems a more proper 
place to repost it.  By the way, the wording in the old patch was 
quite botched; I hope I've made better this time.

Regards,
 Stefano
From e1469cc48cf976fd8c40359c9336eb7fe75e588c Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 28 Feb 2010 15:19:47 +0100
Subject: [PATCH] Document surprising behaviour of AC_PROG_{CC,CXX,F77,FC}.

* doc/autoconf.texi (Compilers and Preprocessors): Explicitly
tell that, of the macros AC_PROG_{CC,CXX,F77,FC}, only the first
expanded one will check for object file extension etc, and fail
if that doesn't work.
Initial report by Stefano Lattarini, first explaination by
Ralf Wildenhues.  Final patch by Stefano Lattarini.
---
 ChangeLog |   11 +++
 doc/autoconf.texi |9 +
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 98e0b31..0ae1a1b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-02-28  Stefano Lattarini  stefano.lattar...@gmail.com
+	Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+	Document surprising behaviour of AC_PROG_{CC,CXX,F77,FC}.
+	* doc/autoconf.texi (Compilers and Preprocessors): Explicitly
+	tell that, of the macros AC_PROG_{CC,CXX,F77,FC}, only the first
+	expanded one will check for object file extension etc, and fail
+	if that doesn't work.
+	Initial report by Stefano Lattarini, first explaination by
+	Ralf Wildenhues.  Final patch by Stefano Lattarini.
+
 2010-02-26  Eric Blake  ebl...@redhat.com
 
 	Optimize AC_REPLACE_FUNCS.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 3dfeda2..941ff04 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -6863,6 +6863,15 @@ the executables can't be run, and cross-compilation is not enabled, they
 fail too.  @xref{Manual Configuration}, for more on support for cross
 compiling.
 
+Also, it's important to understand that only the first expanded one of
+the macros @code{AC_PROG_CC}, @code{AC_PROG_CXX}, @code{AC_PROG_F77}
+and @code{AC_PROG_FC} will check for object file extension and default
+executable file name, and fail if that doesn't work.  If you need to
+know for sure whether any of the compilers work, then you'll have to
+add a compile, link, or run test to find out.  This behaviour may seem
+surprising, but probably it cannot be fixed without breaking backward
+compatibility in some way.
+
 @menu
 * Specific Compiler Characteristics::  Some portability issues
 * Generic Compiler Characteristics::  Language independent tests and features
-- 
1.6.5

Re: document a surprising behaviour of macros AC_PROG_{CC,CXX,F77}

[Ralf Wildenhues]

Hi Stefano,

thanks for the patch, and sorry for the delay on this.

* Stefano Lattarini wrote on Sun, Feb 28, 2010 at 03:25:09PM CET:
 This topic came up a while ago on bug-autoconf, but the patch I posted 
 there went unnoticed or was ignored.

Well, I put it off for later because the right thing to do here would be
to also add a set of AC_PROG_{CC,...}_WORKS macros that people can then
use.  Also, a statement like this:

 This behaviour may seem
 +surprising, but probably it cannot be fixed without breaking backward
 +compatibility in some way.

states we've given up on this, whereas the reason I've put it off was
I haven't done enough research to know for sure whether we can safely
change semantics.

The use of AC_REQUIRE tends to require us to provide macros which do not
take arguments in the vast number of default uses, so that we can easily
let them be required.  Adding options IF-FAILS arguments to the
AC_PROG_{CC,...} macros is bad because some of them already have
optional arguments, some used to have them, and they are often
AC_REQUIREd without options.

IOW, I'd prefer to not promise anything now which we may be able to fix
in a better way later.

Cheers,
Ralf