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
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
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
On Jul 29, 2010, at 11:32 AM CDT, Anthony Chan wrote:
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
Changing to parentheses is fine. If we did care, the best fix isn't changequote, but a pair of quadrigraphs instead: [default is yes] becomes: @<:@default is yes@:>@ http://www.gnu.org/software/autoconf/manual/autoconf.html#Quadrigraphs
--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.
Just kill the leading spaces before "[AS_HELP_STRING(". This fixes it.
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.
I disagree. I don't think it's intuitive for people who are unfamiliar with autoconf to realize that specifying "without" or "=no" will disable the valgrind support. It's unlikely to confuse users the way it is, but removing increases the chances of confusion. -Dave
AFAIK, Autoconf's convention of documenting --with option is to describe meaning of --with-PACKAGE, because "configure --help" contains these few lines in the beginning of any of --with. Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Given you have strong opinion of the help string and I don't want to offend you if I don't do it to your liking, you may want to fix this yourself. A.Chan ----- "Dave Goodell" <[email protected]> wrote:
On Jul 29, 2010, at 11:32 AM CDT, Anthony Chan wrote:
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
Changing to parentheses is fine. If we did care, the best fix isn't changequote, but a pair of quadrigraphs instead:
[default is yes]
becomes:
@<:@default is yes@:>@
http://www.gnu.org/software/autoconf/manual/autoconf.html#Quadrigraphs
--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.
Just kill the leading spaces before "[AS_HELP_STRING(". This fixes it.
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.
I disagree. I don't think it's intuitive for people who are unfamiliar with autoconf to realize that specifying "without" or "=no" will disable the valgrind support. It's unlikely to confuse users the way it is, but removing increases the chances of confusion.
-Dave
On Jul 29, 2010, at 12:55 PM CDT, Anthony Chan wrote:
AFAIK, Autoconf's convention of documenting --with option is to describe meaning of --with-PACKAGE, because "configure --help" contains these few lines in the beginning of any of --with.
Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
I'm fully aware of this generic text. It does not change my position.
Given you have strong opinion of the help string and I don't want to offend you if I don't do it to your liking, you may want to fix this yourself.
w.r.t. this with/without issue, there's no work to be done to make me happy with it. It's already the way that I wanted it, which is why I wrote it that way originally. The null change is the easiest change to make... We've now spent about 10x longer discussing the formatting bug than it would have taken me to just fix it. I'll commit the formatting fixes shortly. -Dave
A.Chan
----- "Dave Goodell" <[email protected]> wrote:
On Jul 29, 2010, at 11:32 AM CDT, Anthony Chan wrote:
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
Changing to parentheses is fine. If we did care, the best fix isn't changequote, but a pair of quadrigraphs instead:
[default is yes]
becomes:
@<:@default is yes@:>@
http://www.gnu.org/software/autoconf/manual/autoconf.html#Quadrigraphs
--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.
Just kill the leading spaces before "[AS_HELP_STRING(". This fixes it.
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.
I disagree. I don't think it's intuitive for people who are unfamiliar with autoconf to realize that specifying "without" or "=no" will disable the valgrind support. It's unlikely to confuse users the way it is, but removing increases the chances of confusion.
-Dave
participants (3)
-
Anthony Chan -
chan＠mcs.anl.gov
-
Dave Goodell