[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "libtool" performance...
From: |
Ralf Wildenhues |
Subject: |
Re: "libtool" performance... |
Date: |
Mon, 14 Apr 2008 23:19:44 +0200 |
User-agent: |
Mutt/1.5.17+20080114 (2008-01-14) |
[ since my mails are being dropped for the other lists anyway, I might
as well drop the xorg and gnome-devtools lists ]
* Roland Mainz wrote on Mon, Apr 14, 2008 at 03:26:11PM CEST:
> Ralf Wildenhues wrote:
> > [...] we are currently working on improving things a bit more,
> > targeting improvements that help all shells which support XSI
> > extensions (and falling back to the slow code for other shells).
>
> What do you mean by "XSI extensions" ?
Shells that support Posix and XSI extensions to Posix. Stuff like
${variable%%pattern}
${variable#pattern}
Hmm, they are required by Posix even; I wonder whether they used to be
extensions required by XSI only, or why else we would have chosen that
name. Anyway, that's what I mean.
> BTW: One thing which could be improved in both "libtool" and "dolt"
> (beyond the stuff listed in
> http://www.opensolaris.org/os/project/shell/shellstyle/) would be to get
> rid of the "echo" h*ll - almost every version of Unix/Linux and shell
> has it's own version of "echo"
I'm not sure what you're talking about: the configure part of Libtool
looks whether 'echo' doesn't interpret backslashes, and otherwise
searches for a (preferably builtin) command that prints without
expanding. And of course we also try printf, but it's known to be buggy
on some systems. It sets $ECHO to the preferred choice.
If you're experiencing a quoting bug, or a system where we choose a
non-builtin for $ECHO where a builtin would do the job just as well,
then please report a bug.
Also, some of the recommendations in the link you quote are rather
questionable. For example, the code in
<http://www.opensolaris.org/os/project/shell/shellstyle/#use_external_filters_only_for_large_datasets>
is much more portably (and likely faster, too) replaced by
case $x in *foo*) do_something;; esac
at the expense of using BREs over EREs, of course.
Also, some items explicitly recommend to use nonportable constructs over
portable ones, even without efficiency concerns. This is not a way to
go for Libtool.
> Question for both "dolt" and "libtool" developers:
> Where should I send bug reports/patches to ?
Libtool patches go to address@hidden Note that nontrivial
patches require copyright assignment to the FSF.
Cheers,
Ralf
- Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half, (continued)
- Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half, Michel BRIAND, 2008/04/09
- Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half, David Johnson, 2008/04/09
- "libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half, Roland Mainz, 2008/04/11
- "libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half, Roland Mainz, 2008/04/11
- Re: "libtool" performance... / was: Re: Announcing Dolt, a drop-inLibtool replacement which cuts build timesin half, Roland Mainz, 2008/04/11
- Re: "libtool" performance... / was: Re: Announcing Dolt, a drop-inLibtool replacement which cuts build timesin half, Ralf Wildenhues, 2008/04/11
- Re: "libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half, Attila Kinali, 2008/04/11
- Re: "libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half, Daniel Stone, 2008/04/11
- Re: "libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half, Alan Coopersmith, 2008/04/15