Conditionally including macros that require a newer autoconf version

Discussion:

Rainer Gerhards

2016-07-26 07:06:55 UTC

Hi all,

please excuse my limited autoconf knowledge.

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.

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

Unfortunately, this does not work either. As it looks, autoreconf
already checks the macro dependencies, so this happens at a stage
before the switch can be used:

http://build.rsyslog.com:8010/builders/liblognorm%20centos6%20rsyslog/builds/83/steps/shell/logs/stdio

I wonder if there is any way to disable that macro, other than
manually removing and re-inserting it on a as-needed basis (which
really is not a good solution).

Any advise is deeply appreciated.
Rainer

Nick Bowler

2016-07-26 17:55:51 UTC

Permalink

Post by Rainer Gerhards
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.

Post by Rainer Gerhards
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
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

Rainer Gerhards

2016-07-28 08:59:50 UTC

Permalink

Post by Nick Bowler

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.

Thanks for the hint. I finally found a somewhat simpler solution which
I think covers my case very well. I check if the AX_COMPILE_FLAGS
macro (plus helper) is present and use it if so. This is based on the
assumption that a system which actually has the macro on it will also
be recent enough to support it (feature check vs. version check). I
hope this sounds like a good plan from an autoconf perspective. I have
used this code:

m4_ifdef([AX_IS_RELEASE], [
AX_IS_RELEASE([git-directory])
m4_ifdef([AX_COMPILER_FLAGS], [
AX_COMPILER_FLAGS()
], [
if test "$GCC" = "yes"
then CFLAGS="$CFLAGS -W -Wall -Wformat-security -Wshadow
-Wcast-align -Wpointer-arith -Wmissing-format-attribute -g"
fi
AC_MSG_WARN([missing AX_COMPILER_FLAGS macro, not using it])
])
], [
if test "$GCC" = "yes"
then CFLAGS="$CFLAGS -W -Wall -Wformat-security -Wshadow
-Wcast-align -Wpointer-arith -Wmissing-format-attribute -g"
fi
AC_MSG_WARN([missing AX_IS_RELEASE macro, not using
AX_COMPILER_FLAGS macro because of this])
])

Post by Nick Bowler

"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.

will do on further questions.

Thanks again for the help!
Rainer