On Mon, Mar 06, 2000 at 02:46:27PM +0100, Akim Demaille wrote:
: | 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.
That's why I feared it wasn't kosher...
: 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?
Well, it's a macro for large CVS projects, where you on the client-side
sometimes needs to check out additional modules, remove old modules or
directories and such things that can happen if the source file hierarchy
is reorganized. Things that goes beyond what you can accomplish with
"cvs update -dP".
To enable easier updating of such things, I've written a macro that will
display the update procedure and execute it for you if you are willing to
take the chance.
SIM_AC_UPDATE_SOURCES(
[ -f examples/ChangeLog ],
[ rm -rf examples
grep -v "D/examples/" CVS/Entries > CVS/Entries.bak.$$
mv CVS/Entries.bak.$$ CVS/Entries
cvs co SoQtExamples
])
For each step the source hierarchy is updated, I can add another
SIM_AC_UPDATE_SOURCES macro in configure.
If the $1 test fails, the update procedure in $2 is displayed, with
some explanation text about what the problem is and that you can use
--with-auto-update if you feel brave. If there are several of these
updates that fail, I want the header text only to be displayed before
the first failing macro, and the footer text only to be displayed after
the last SIM_AC_UPDATE_SOURCES invocation. The SIM_AC_UPDATE_SOURCES
macros are invoked just below AC_INIT(), and I exit configure on the
last one if the sources aren't up-to-date with regards to the tests.
I could of course create a SIM_AC_UPDATE_SOURCES_FINALIZE() macro and
put it below the last SIM_AC_UPDATE_SOURCES() macro, but it doesn't
look as slick in the configure.in file ;) and I like a good challenge.
I might very well go for that solution, though, just to be kosher...
: | 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.
It is defined to a simple number.
: | [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.
$1 and $2 should be valid shell variable names.
: | 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.
You're right about that, but it wouldn't happen the way I use the macro.
: I tend to think you should look at AC_CONFIG_COMMANDS_PRE and
: AC_CONFIG_COMMANDS_POST, they might provide solutions to your problem.
They don't seem to be right for how I use SIM_AC_UPDATE_SOURCES.
Lars J
