[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
multiline AC_TRY_COMMAND: bug or feature?
From: |
Tim Van Holder |
Subject: |
multiline AC_TRY_COMMAND: bug or feature? |
Date: |
Sun, 28 Jan 2001 19:43:30 +0100 |
Just ran into this with CVS CVS (not a typo). Its configure.in has
if AC_TRY_COMMAND([make -f conftestmake 2>&1 >/dev/null
|grep ^BSD\ VPATH\ bug\ present\$ >/dev/null]) ; then
ccvs_cv_bsd_make_vpath_bug=yes
else
ccvs_cv_bsd_make_vpath_bug=no
fi
With 2.13, this had
... ac_try='make -f conftestmake 2>&1 >/dev/null |grep ^BSD\ VPATH\ bug\
present\$ >/dev/null' ...
But CVS autoconf gives
... (eval echo "$as_me:3053: \"make -f conftestmake 2>&1 >/dev/null
|grep ^BSD\ VPATH\ bug\ present\$ >/dev/null\"") >&5
(eval make -f conftestmake 2>&1 >/dev/null
|grep ^BSD\ VPATH\ bug\ present\$ >/dev/null) 2>&5
...
At the very least, more quoting is needed to ensure config.log has the
actual command being run (as it stands, the backslashes would be lost).
But more annoying is the fact that preserving the newline in the command
causes bash to see:
(eval make -f conftestmake 2>&1 >/dev/null; |grep ^BSD\ VPATH\ bug\ present\$
>/dev/null)
which is clearly invalid.
Is this a bug, or simply a feature that happens to be incompatible with
the behaviour of earlier versions of autoconf?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- multiline AC_TRY_COMMAND: bug or feature?,
Tim Van Holder <=