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.

[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