Autoconf 2.71

[nigoroll]

The first commit just pulls in macros from autoconf-archive 2.71
The second commit renovated configure.ac for compatibility with both 2.71 and 2.69, which is kept the minimum in order to not cause too much of a stir.

[nigoroll]

FTR: Apologies for the force-push noise, I had messed up my local repo for a moment.

[nigoroll]

I saw this on an older system:

hpack/vhp_gen_hufdec.c: In function 'tbl_free':
hpack/vhp_gen_hufdec.c:102:2: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned i = 0; i < table->n; i++) {

So maybe I misread the documentation?

[nigoroll]

So it seems we need to keep AC_PROG_CC_C99 unless we were willing to require autoconf >= 2.70

[nigoroll]

Again back to draft status. I am not so sure about the varnish.m4 changes any more at this point.

[nigoroll]

@dridi could I please ask for your advice / opinion about this aspect?
To avoid issues with API headers accidentally making use of GNU/POSIX extensions, I would think that we should also, by default, enable them for vmods.
Yet with a sane vmod configure.ac like the one from a certain development kit, this will lead to the following warnings:

configure.ac:22: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
aclocal.m4:9533: _VARNISH_VMOD_CONFIG is expanded from...
aclocal.m4:9579: _VARNISH_VMOD is expanded from...
aclocal.m4:9763: VARNISH_VMODS is expanded from...
configure.ac:22: the top level
configure.ac:22: warning: AC_LINK_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
aclocal.m4:9533: _VARNISH_VMOD_CONFIG is expanded from...
aclocal.m4:9579: _VARNISH_VMOD is expanded from...
aclocal.m4:9763: VARNISH_VMODS is expanded from...
configure.ac:22: the top level
configure.ac:22: warning: AC_CHECK_INCLUDES_DEFAULT was called before AC_USE_SYSTEM_EXTENSIONS
aclocal.m4:9533: _VARNISH_VMOD_CONFIG is expanded from...
aclocal.m4:9579: _VARNISH_VMOD is expanded from...
aclocal.m4:9763: VARNISH_VMODS is expanded from...
configure.ac:22: the top level

In turn, those can be avoided by the following change to call the VARNISH_* macros before any compiler/linker related macros

diff --git a/configure.ac b/configure.ac
index 178f2e9..2d9e75c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,10 +6,6 @@ AC_CONFIG_HEADERS([config.h])
 
 AM_INIT_AUTOMAKE([1.12 -Wall -Werror foreign parallel-tests])
 AM_SILENT_RULES([yes])
-AM_PROG_AR
-
-LT_PREREQ([2.2.6])
-LT_INIT([dlopen disable-static])
 
 AC_ARG_WITH([rst2man],
        AS_HELP_STRING(
@@ -21,6 +17,11 @@ AC_ARG_WITH([rst2man],
 VARNISH_PREREQ([6.0.0])
 VARNISH_VMODS([test])
 
+AM_PROG_AR
+
+LT_PREREQ([2.2.6])
+LT_INIT([dlopen disable-static])
+
 AC_CONFIG_FILES([
        Makefile
        src/Makefile

but I am not sure if this is the best option.

[dridi]

In varnish.m4, the reason why some macros are not called directly but through AC_REQUIRE instead is to avoid multiple evaluations. For example, a source tree like varnish-modules with multiple VMODs or a hypothetical project where a VMOD interacts with a VUT would result in a more bloated configure script (and maybe other undesirable effects I'm not remembering, like checks appearing several times in the output).

I don't think we can should call AC_LANG(C) on behalf of VMOD/VUT authors, but we can probably safely AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS]) since I believe a few of our headers contain definitions based on such extensions.

For c99 detection we should probably do something like:

# Check for c99, remove the unset case when AC_PREREQ >= 2.70
ac_prog_cc_stdc=unset
AC_PROG_CC
AS_CASE([$ac_prog_cc_stdc],
       [no|c89], [AC_MSG_ERROR([Support for c99 or later is required])],
       [unset], [AC_PROG_CC_C99])

Just calling AC_PROG_CC is no longer enough, but I don't expect to run into c89-only compilers any time soon. I have not tested the snippet yet, don't assume it works as intended.

Regarding the autoconf archive, I think we are still better off bundling only the things we care about.

[nigoroll]

re @dridi

• regarding AC_REQUIRE(), it seems I was somehow under the impression that vmod autoconf would not work if we used it, but I can not reproduce this any more, so I will assume that I had made some other mistake.
• regarding AC_LANG(C) for vmods, this is what we had so far. Can there really be vmods without at least some glue code in C?
• Regarding AC_PROG_CC_C99, we would like to avoid the autoconf warning The macro `AC_PROG_CC_C99' is obsolete.. But if I understand the autoconf code correctly, this warning is already emitted whenever the macro gets expanded, which seems to be the case also for the snippet you have suggested.
  So at this point I would think that just accepting the warning until we require a newer autoconf should be a practical approach which does not cause much harm.

I have force-pushed the branch accordingly after testing with autoconf 2.71 and 2.69

[nigoroll]

Friendly ping to @dridi