Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.

This avoids warnings from Autoconf 2.68 about missing use of AC_LANG_PROGRAM and friends.

---

The patch should not cause any semantic changes in the generated configure script.

Thanks,
Ralf

 aclocal.m4   |    4 ++--
 configure.ac |   56 +++++++++++++++++++-------------------------------------
 2 files changed, 21 insertions(+), 39 deletions(-)

index d399de2..f11bc7e 100644
@@ -13,7 +13,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
          git_cv_socklen_t_equiv=
          for arg2 in "struct sockaddr" void; do
             for t in int size_t unsigned long "unsigned long"; do
-               AC_TRY_COMPILE([
+               AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
                   #include <sys/types.h>
                   #include <sys/socket.h>
 

@@ -21,7 +21,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
                ],[
                   $t len;
                   getpeername(0,0,&len);
-               ],[
+               ])],[
                   git_cv_socklen_t_equiv="$t"
                   break 2
                ])

1.7.4.rc0

This part belongs in the commit message too, imho (though no need to resend just for that, of course).

* Jonathan Nieder wrote on Sun, Jan 02, 2011 at 08:59:53AM CET:

Yeah, you're right.

Allow me to quote autoconf-2.68/NEWS:

** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have a compelling reason why you cannot use AC_LANG_SOURCE but must avoid the warning.

The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM} take care to actually supply the previously computed set of #defines (and include the standard headers if so desired), for preprocessed languages like C and C++. In the above case, AC_LANG_PROGRAM is already used, but not sufficiently m4-quoted, so that the autoconf warning will be triggered bogusly.

The general rule for m4 quotation is: one set of quotes for each macro argument, e.g.:
MACRO1([arg with MACRO2([arg], [arg])], [arg], ...)

and for innermost arguments which need to undergo no m4 expansion at all a double set of quotes should be used, e.g.:
AC_LANG_SOURCE([[int s[42]; /* Program sources containing brackets. */]])

Only for some special macros that need to be expanded before recursion no quoting should be used.

These and more rules are described in detail in 'info Autoconf "Programming in M4"'. The rules can often be relaxed when the macro arguments contain no active characters like comma, brackets or other macro invocations themselves, but IMVHO it is easier getting used to just quote things normally.

Likewise this is just underquotation leading to false positive.

See above.

I would be happy to update the patch in a way that makes it more helpful, but most of the above is fairly general Autoconf rules, so I'm not sure what you need (being blinded by looking at this stuff too often).

Cheers,
Ralf

A little essay in the commit message should be sufficient. Something vaguely like this, maybe. (cut and pasted from the above)

This avoids warnings from Autoconf 2.68 about missing use of AC_LANG_PROGRAM and friends.

Allow me to quote autoconf-2.68/NEWS:

** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have a compelling reason why you cannot use AC_LANG_SOURCE but must avoid the warning.

The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM} take care to actually supply the previously computed set of #defines (and include the standard headers if so desired), for preprocessed languages like C and C++.

In some cases, AC_LANG_PROGRAM is already used but not sufficiently m4-quoted, so we just need to add another set of [quotes] to prevent the autoconf warning from being triggered bogusly. Quoting all arguments (except when calling special macros that _need_ to be expanded before recursion) is better style, anyway. These and more rules are described in detail in 'info Autoconf "Programming in M4"'.

The patch should not cause any semantic changes in the generated configure script.

This avoids warnings from Autoconf 2.68 about missing use of AC_LANG_PROGRAM and friends.

Quoting autoconf-2.68/NEWS:

** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have a compelling reason why you cannot use AC_LANG_SOURCE but must avoid the warning.

The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM} take care to actually supply the previously computed set of #defines (and include the standard headers if so desired), for preprocessed languages like C and C++.

In some cases, AC_LANG_PROGRAM is already used but not sufficiently m4-quoted, so we just need to add another set of [quotes] to prevent the autoconf warning from being triggered bogusly. Quoting all arguments (except when calling special macros that _need_ to be expanded before recursion) is better style, anyway. These and more rules are described in detail in 'info Autoconf "Programming in M4"'.

The patch should not cause any semantic changes in the generated configure script.

---

* Jonathan Nieder wrote on Sun, Jan 02, 2011 at 11:00:12AM CET:

Thank you for your help! Resending like this.

Cheers,
Ralf

 aclocal.m4   |    4 ++--
 configure.ac |   56 +++++++++++++++++++-------------------------------------
 2 files changed, 21 insertions(+), 39 deletions(-)

index d399de2..f11bc7e 100644
@@ -13,7 +13,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
          git_cv_socklen_t_equiv=
          for arg2 in "struct sockaddr" void; do
             for t in int size_t unsigned long "unsigned long"; do
-               AC_TRY_COMPILE([
+               AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
                   #include <sys/types.h>
                   #include <sys/socket.h>
 

@@ -21,7 +21,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
                ],[
                   $t len;
                   getpeername(0,0,&len);
-               ],[
+               ])],[
                   git_cv_socklen_t_equiv="$t"
                   break 2
                ])

1.7.4.rc0

* Ralf Wildenhues wrote on Sun, Jan 02, 2011 at 11:24:55AM CET:

I'd like to ping this patch:
http://thread.gmane.org/gmane.comp.version-control.git/164409/focus=164416

which IIUC addresses all previous comments in the thread and was otherwise noncontroversial. If there is anything else left to do, I'd be happy to hear about it.

Thanks,
Ralf

From: Ralf Wildenhues <[email protected]>
Date: Sun, 2 Jan 2011 11:24:55 +0100

Avoid warnings from Autoconf 2.68 about missing use of AC_LANG_PROGRAM and friends.

Quoting autoconf-2.68/NEWS:

** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have a compelling reason why you cannot use AC_LANG_SOURCE but must avoid the warning.

The underlying reason for that change is that AC_LANG_{SOURCE,PROGRAM} take care to supply the previously computed set of #defines (and include standard headers if so desired) for preprocessed languages like C and C++.

In some cases, AC_LANG_PROGRAM is already used but not sufficiently m4-quoted, so we just need to add another set of [quotes] to prevent the autoconf warning from being triggered bogusly. Quoting all arguments (except when calling special macros that need to be expanded before recursion) is better style, anyway. These and more rules are described in detail in 'info Autoconf "Programming in M4"'.

No change in the resulting config.mak.autogen after running ./configure intended.

---
Hi,

The point of using AC_LANG_PROGRAM is that some magic (like #define _GNU_SOURCE) could be added before the code used to perform a feature test. And that is good --- we have similar magic in git-compat-util.h, for similar reasons.

The worrisome aspect is that autoconf's magic and git's magic are unlikely to work the same way, making the detection inaccurate.

That said, at least this patch doesn't make it worse. Consistency is nice. And sometimes squashing a warning is worthwhile just for the sake of squashing a warning, so other warnings don't get lost in the noise.

 aclocal.m4   |    4 ++--
 configure.ac |   56 +++++++++++++++++++-------------------------------------
 2 files changed, 21 insertions(+), 39 deletions(-)

index d399de2..f11bc7e 100644
@@ -13,7 +13,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
          git_cv_socklen_t_equiv=
          for arg2 in "struct sockaddr" void; do
             for t in int size_t unsigned long "unsigned long"; do
-               AC_TRY_COMPILE([
+               AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
                   #include <sys/types.h>
                   #include <sys/socket.h>
 

@@ -21,7 +21,7 @@ AC_DEFUN([TYPE_SOCKLEN_T],
                ],[
                   $t len;
                   getpeername(0,0,&len);
-               ],[
+               ])],[
                   git_cv_socklen_t_equiv="$t"
                   break 2
                ])

1.7.4.1