Re: Conditionally including macros that require a newer autoconf version

[Nick Bowler]

On 2016-07-26, Rainer Gerhards <address@hidden> wrote:
> I want to add the AX_COMPILE_FLAGS macro to my projects in order to
> produce better code. Unfortunately, this macro (more precise: it's
> helpers) require at least autoconf 2.64. This is not available on a
> number of platforms, Centos 6 is an example (2.61). I don't want to
> prevent users from building my projects just because the
> AX_COMPILE_FLAGS macro requires newer autoconf -- after all, this is
> more or less a development aid.

Most users shouldn't need any particular version of autoconf:  One of
the main features of autoconf is that autoconf is not required simply to
build the package: its output is a portable shell script which should be
included in your distribution tarballs.

For the same reason, making features conditional on the autoconf version
has a major problem: distributions built with older autoconf will be
missing features that suddenly appear when people autoreconf with a
newer autoconf.  Autoconf is not hard to install, it's only needed
when regenerating the configure script, so IMO it's not too much to
ask those users to install a newer version as a dependency.

Nevertheless, what you're asking for is still possible.  As you observed,
AC_AUTOCONF_VERSION was added in version 2.62.  But your extra feature
requires 2.64, so it won't work in older versions anyway.  Thus you can
use m4_ifdef to test the existence of AC_AUTOCONF_VERSION, then if it
exists test the actual version string, then only if all checks out
expand your version-dependent macros.

> I initially tried to disable it based on the autoconf version. But I
> found out that the macro that obtains this version requires 2.62,
> which I also do not have on many platforms.  So I tried to add a
> conditional switch to disable this macro:
>
> https://github.com/rsyslog/liblognorm/pull/213/commits/61306142e0f4c972df820d161cc960db563afa53

This link seems to be dead:

  "We went looking everywhere, but couldn't find those commits".

For the benefit of the mailing list archives, it is best to include your code
(ideally a small, reproducible test case) directly in the body of your message.

Hope that helps,
  Nick