Hi Dave, It seems there is quoting issue with AC_HELP_STRING (not sure how the automake/libtool to get "[..]" in their help stringd), but if you replace "[default is yes]" to "(default is yes)", autoconf-2.64 will process configure.in happily. I think we can use m4's change-quote if you really want "[..]". With 2.64, configure --help gives --without-valgrind to disable valgrind support (such as because of version issues) --with-valgrind=PATH use valgrind headers installed in PATH (default is yes) Notice things still don't align correctly. BTW, I think the AS_HELP_STRING of "--without-valgrind" (the 1st one) is redundant, I suggest removing it if you are OK with it. A.Chan ----- "Dave Goodell" <[email protected]> wrote:
I'll try to take a look at it later. In the interim, if you see a good workaround, just fix it.
-Dave
On Jul 27, 2010, at 3:46 PM CDT, [email protected] wrote:
I updated maint/updatefiles to allow 2.64, but autoreconf failed on src/mpl. It seem 2.64's autoconf has problem with mpl's consecutive use of AS_HELP_STRINGs.
/home/chan/mpich_work/mpich2/src/mpl> autoreconf -vif autoreconf: Entering directory `.' autoreconf: configure.in: not using Gettext autoreconf: running: aclocal --force -I confdb autoreconf: configure.in: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `confdb'. libtoolize: copying file `confdb/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `confdb'. libtoolize: copying file `confdb/libtool.m4' libtoolize: copying file `confdb/ltoptions.m4' libtoolize: copying file `confdb/ltsugar.m4' libtoolize: copying file `confdb/ltversion.m4' libtoolize: copying file `confdb/lt~obsolete.m4' autoreconf: running: /home/chan/autoconf/2.64/bin/autoconf --force configure:1510: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
However autoconf-2.65 (and of course 2.63) works OK on the file,
but
output of configure --help on the valgrind option does not look quite right....
--without-valgrind to disable valgrind support (such as because of version issues) --with-valgrind=PATH use valgrind headers installed in PATH [default], [is], [yes] Maybe there is a bug...
A.Chan