[Top][All Lists]

[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 (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

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

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

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


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


reply via email to

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