Re: Severe performance problem and proposed solution
Paul == Paul Eggert [EMAIL PROTECTED] writes:
From: Zack Weinberg [EMAIL PROTECTED] Date: Tue, 26 Feb 2002
17:21:14 -0800
In this case, we know that the problem is due to the creation of
thousands of temporary files which each subshell invocation creates
hard links to. If, I say if, someone can generate a small script
that causes the shell to do this, then it could look into /tmp for
the scratch files.
Paul But such a method cannot be reliable in general, since you don't
Paul know what other processes are doing. Some other process may be
Paul running 'configure' with a buggy shell at the same time that
Paul you're running 'configure' with a working shell (not entirely
Paul implausible, if you're using a parallelized 'make').
And anyway, that's probably not what we want to do. What we want, is
to find a reliable `echo', or any means that would help us remove the
thousands of heredocs we have. Then, as a fallback, just as libtool,
we can have the very top of configure become a proper (= good for us)
echo implemented via here docs.
Therefore the test will be merely checking that the echo, or printf or
whatever, is good enough for us.
This is a bit a libtool:
# Check that we have a working $echo.
if test X$1 = X--no-reexec; then
# Discard the --no-reexec flag, and continue.
shift
elif test X$1 = X--fallback-echo; then
# Avoid inline document here, it may be left over
:
elif test X`($echo '\t') 2/dev/null` = 'X\t'; then
# Yippee, $echo works!
:
else
# Restart under the correct shell, and then maybe $echo will work.
exec $SHELL $0 --no-reexec ${1+$@}
fi
if test X$1 = X--fallback-echo; then
# used as fallback echo
shift
cat EOF
$*
EOF
exit 0
fi
(Actually, it's been a while I've been thinking having M4sh equipped
with command substitutes: it would start by a case/esac and provide us
with echo, ln supporting -s, etc.)
Paul Currently 'configure' switches to Bash if the current shell
Paul mishandles LINENO and if Bash exists and handles LINENO
Paul correctly. We could modify things so that instead it switches
Paul to Bash if the current shell is not Bash and if Bash exists and
Paul handles LINENO correctly. That would be a bit of a hack, but it
Paul would do the trick, no?
Sure, but I don't think targeting at Bash only is right :)
Get paid cash every time you receive email!
Earn a dime every time you receive email! Sign up FREE at: Here ¡¡===¸ÃÓʼþʹÓà ¿ÆÌØÓʼþȺ·¢Èí¼þ ·¢ËÍ,ÓʼþÄÚÈÝÓë¿ÆÌØÈí¼þÎ޹ؿÆÌØÈí¼þ http://www.caretop.com===
Re: Severe performance problem and proposed solution
From: Akim Demaille [EMAIL PROTECTED]
Date: 27 Feb 2002 10:05:42 +0100
What we want, is to find a reliable `echo', or any means that would
help us remove the thousands of heredocs we have.
elif test X`($echo '\t') 2/dev/null` = 'X\t'; then
# Yippee, $echo works!
Unfortunately this approach won't work in the long run.
POSIX 1003.2-1992 allows echo '\t' to output backslash-t, but
POSIX 1003.1-2001 requires that it must output a tab character.
Eventually shells will head in that direction, albeit reluctantly.
Here's an idea. How about if we use expr instead of cat? That is
allowed by the GNU coding standards, and it handles backslash
correctly. That is, instead of doing this:
cat __ACEOF
some very
long string
with funny characters '\\
and with $SHELL expansions in it
__ACEOF
we do this:
expr Xsome very
long string
with funny characters \'\\
and with $SHELL expansions in it : 'X\(.*\)'
If __ACEOF is quoted, the expr version should use ' instead of ,
and should quote ' rather than of course.
The problems I see with this approach are:
* expr may be limited in the length of the string that it can handle.
But we already have this problem with some extent with __ACEOF;
and we already use expr in similar ways so there is some precedent.
* is tricky, e.g.
cat __ACEOF
${foo+abc}
__ACEOF
will be mishandled if we blindly escape all s in the expr version.
But that is a problem no matter what program we substitute for
__ACEOF.
* expr exits with nonzero status if the string is empty. But we're
already ignoring the exit status of cat, so I don't see this as a
real problem.
AC_PROG_SED: rejected?
Hello, I submitted a patch some time ago for adding a macro to autoconf for determining a sed that would truncate the least amount of output (preferring gnu sed also). I haven't seen any discussion of it after my last tweak to the patch, but it hasn't been checked in. I know that the queue can be long, but I just wanted to make sure it wasn't rejected for some reason. Thanks, Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: AC_PROG_SED: rejected?
From: Robert Boehne [EMAIL PROTECTED] Date: Wed, 27 Feb 2002 11:05:38 -0600 I haven't seen any discussion of it after my last tweak to the patch, but it hasn't been checked in. I assume you're talking about this URL? http://mail.gnu.org/pipermail/autoconf-patches/2002-January/008138.html I don't know of any reason that the patch was rejected, so it's probably still in the queue. The ChangeLog says that Akim removed AC_PROG_SED on 2000-02-10; perhaps he can explain why it was removed. AC_PROG_SED wasn't in Autoconf 2.13, but the ChangeLog doesn't say when or why it was added. Presumably it was some internals thing. In your message you wrote: I was thinking that I would tack on LT_ to the macro name (after expanding post-2.50 Autoconf macros in it), add it to Libtool, and then when AC_PROG_SED is available in a released version of Autoconf, remove my private copy. Does that sound sane? and the answer to that question is yes.
autoconf.texi node names with dots
I noticed the autoconf index entries which have dots in the node names don't work from emacs (21.1). Eg. using i to find CONFIG_COMMANDS ought to go to Obsolete config.status Use (from the Environment Variables index), but gives an error No such anchor in tag table or node in tag table or file: Obsolete config Though it might look like an emacs problem, the texinfo docs under Node Line Requirements assert that a period is not allowed in a node name. Dunno what to do about it though, config.status is the name of the script, and deserves to be referred to as such.
