AS_ECHO_N in util-macros

Gaetan Nadon memsize at videotron.ca
Tue Feb 14 08:29:43 PST 2012


On 12-02-13 06:13 PM, Jeremy Huddleston wrote:
> I just noticed this when using autoconf-2.61 ... does AS_ECHO_N require a newer version of autoconf?  Can we work around that requirement?
>
> ...
> configure:4924: error: possibly undefined macro: AS_ECHO_N
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> ...
The AS_ECHO_N macro was introduced in 2.62. This information is not
written in the autoconf manual, so it is very difficult to catch.

I think we can use AS_ECHO as the string is not sent to stdout but
stored in a variable. There is therefore no new line to suppress.

    dnl Some hackery here since AC_CACHE_VAL can't handle a non-literal
    varname
            AC_MSG_CHECKING([if $CC supports ]flag[])
            cacheid=`*AS_ECHO*([xorg_cv_cc_flag_]flag[])`
            AC_CACHE_VAL(AS_TR_SH($cacheid),
                     [AC_LINK_IFELSE([AC_LANG_PROGRAM([int i;])],
                             [eval AS_TR_SH($cacheid)=yes],
                             [eval AS_TR_SH($cacheid)=no])])

            CFLAGS="$xorg_testset_save_CFLAGS"

            eval supported=$AS_TR_SH($cacheid)
            AC_MSG_RESULT([$supported])
            if test "$supported" = "yes" ; then
                $1="$$1 ]flag["
                found="yes"
            fi
        fi
    ])

I have tried on a module and the out put is identical:

    xorg_cv_cc_flag__Wall=yes
    xorg_cv_cc_flag__Wbad_function_cast=yes
    [...]

I am not sure if there would be some cases where "non-literal varname"
would fail, as I doubt they would have contained a new line character.

>
>
> On Jan 22, 2012, at 5:16 AM, Jon TURNEY <jturney at kemper.freedesktop.org> wrote:
>
>> xorg-macros.m4.in |   34 +++++++++++++++++++++-------------
>> 1 file changed, 21 insertions(+), 13 deletions(-)
>>
>> New commits:
>> commit a1809fde56e45639556a44fd3c3ef9213204c5a9
>> Author: Jon TURNEY <jon.turney at dronecode.org.uk>
>> Date:   Mon Jan 2 19:42:10 2012 +0000
>>
>>    Cache the results of checking compiler flag support in XORG_TESTSET_CFLAG
>>
>>    Since checking all those warning flags takes an amount of time I find irritating,
>>    here is an attempt at caching the results of checking compiler warning flag support
>>
>>    A couple of aspects which need definitely need review or testing:
>>
>>    * I've tried to get things right when not the first flag in the list of alternates is
>>    supported, but this really needs testing with a compiler other than gcc
>>
>>    * The cache variable naming policy is a bit opaque me, so the names used may need corecting
>>
>>    * I've tried to be careful, but who knows what portability sins I have committed :-)
>>
>>    This change reduces the time to run the ./configure script produced from a configure.ac
>>    containing just
>>
>>    AC_INIT([test], 1.0)
>>    XORG_COMPILER_FLAGS
>>    XORG_CWARNFLAGS
>>    XORG_STRICT_OPTION
>>    AC_OUTPUT()
>>
>>    from ~60s to ~20s on my cygwin machine, and from ~15s to ~9s on a linux VM running on the
>>    same hardware
>>
>>    v2: AS_TR_SH transforms characters which are invalid in shell variable names, so we don't
>>    have to use sed to transform spaces ourself
>>
>>    Signed-off-by: Jon TURNEY <jon.turney at dronecode.org.uk>
>>    Reviewed-by: Gaetan Nadon <memsize at videotron.ca>
>>
>> _______________________________________________
>> xorg-commit mailing list
>> xorg-commit at lists.x.org
>> http://lists.x.org/mailman/listinfo/xorg-commit
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120214/85765de3/attachment.htm>


More information about the xorg-devel mailing list