autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conditionally including macros that require a newer autoconf version


From: Rainer Gerhards
Subject: Re: Conditionally including macros that require a newer autoconf version
Date: Thu, 28 Jul 2016 10:59:50 +0200

On Tue, Jul 26, 2016 at 7:55 PM, Nick Bowler <address@hidden> wrote:
> 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.

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])
])

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

will do on further questions.

Thanks again for the help!
Rainer



reply via email to

[Prev in Thread] Current Thread [Next in Thread]