autoconf-patches
[Top][All Lists]
Advanced

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

Re: AC_DEFUN_ONCE semantics


From: Paolo Bonzini
Subject: Re: AC_DEFUN_ONCE semantics
Date: Tue, 27 Jan 2009 09:03:24 +0100
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

> What I'm more concerned about is all the macros that will now be turned
> into being AC_DEFUN_ONCE, and which users have been using for a long
> time and won't expect to have their semantics changed.  I hope this set
> will be small.  AC_PROG_* shouldn't be in it, for compatibility reasons.

I think that only the following macros must absolutely be defined with
AC_DEFUN_ONCE: AC_CANONICAL_*, AC_USE_SYSTEM_EXTENSIONS.

Regarding AC_PROG_* macros, I think most of them pose no problems, but I
agree that this should be left to a future version N years down the
road.  Those that do pose problems are:

1) those that find target tools, such as compilers or ranlib.  It is
conceivable that they are placed in an if statement, though technically
wrong.  See indeed
http://www.google.com/codesearch/p?hl=en#e_ObwTAVPyo/configure.in&l=299
-- what a needless complication!  Not even the gcc configure scripts are
so messy (besides, they use --host for --build and --target for --host
wrong... this is their bug 475488 now).

It is also conceivable that they are called multiple times, though
tricky.  My own ACX_PROG_CC_FOR_BUILD macro which is somewhere in the
autoconf archive would fail miserably.

2) AC_PROG_CXX and for a different reason, which is because the lack of
a C++ compiler will abort the configure script.  This is a pity because
PHP and Apache have the following:

  if test -z "$php_cxx_done"; then
            AC_PROG_CXX
            AC_PROG_CXXCPP
            php_cxx_done=yes
  fi

and (if it wasn't for the above misfeature) it would work also for
AC_DEFUN_ONCE'd AC_PROG_CXX{,CPP} with good savings on configure script
size.


Two other points.  First, it's interesting that AC_PROG_LEX is already
defined with AC_DEFUN_ONCE, and since 2001-08-22 for that matter (I
don't really understand why).


Second, Eric, I have a doubt: does this idiom work with the new
AC_DEFUN_ONCE?

  AC_PROVIDE_IFELSE([AC_PROG_CXX],
                    [_AM_DEPENDENCIES(CXX)],
                    [m4_define([AC_PROG_CXX],
                     m4_defn([AC_PROG_CXX])[_AM_DEPENDENCIES(CXX)])])dnl

I think so, but I'd rather ask you?

Paolo




reply via email to

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