| AC_DEFUN([SIM_AC_ITERATOR],
| [AC_DIVERT_PUSH([AC_DIVERSION_INIT])dnl
You should avoid playing with Autoconf's diversions. They are
internals only, and there is no guarantee they won't change. As a
matter of fact, there is a patch in the queue which removes
AC_DIVERSION_INIT (renames actually).
Maybe the problem you want to solve should be handled by Autoconf per
se. Could you expand on it?
| ifelse(defn([sim_ac_$1_count]), [],
ifdef looks better here, and involves less processing, in particular
if the defn of sim_ac_$1_count is big.
| [define([sim_ac_$1_count],1)$2=sim_ac_$1_count],
| [define([sim_ac_$1_count],m4_eval(1+sim_ac_$1_count))$2=sim_ac_$1_count])
Using ifdef([sim_ac_$1_count], [], define([sim_ac_$1_count],0)) then
use it seems more readable to me, but this is nit picking ;).
your comment seems to imply $1 can be more than just a name, hence you
can not just m4_eval(1+sim_ac_$1_count), you should
m4_eval(1+indir([sim_ac_$1_count])). Also, there is a macro named incr.
| AC_DIVERT_POP()dnl
| $1=sim_ac_$1_count
Same here.
| ])
IIUC, in configure you will compare the number of an evaluation with
the highest number, right? But then, what will happen if the last
evaluation is in an if/fi? your code won't be triggered.
I tend to think you should look at AC_CONFIG_COMMANDS_PRE and
AC_CONFIG_COMMANDS_POST, they might provide solutions to your problem.
Akim
- Macro: AC_CONFIG_COMMANDS_PRE(CMDS)
Execute the CMDS right before creating `config.status'. A typical
use is computing values derived from variables built during the
execution of `configure':
AC_CONFIG_COMMANDS_PRE(
[LTLIBOBJS=`echo $LIBOBJS | sed 's/\.o/\.lo/g'`
AC_SUBST(LTLIBOBJS)])
- Macro: AC_CONFIG_COMMANDS_POST(CMDS)
Execute the CMDS right after creating `config.status'.
