OK to apply?
Thanks,
Ralf
2008-04-10 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS) func_xform:
New function.
* libltdl/config/ltmain.m4sh (func_mode_compile): Use it to
avoid two forks with XSI shells.
Index:
OK to apply?
What about eliminating (when progdir='.')
curwd=`cd . pwd`
Do we know when (with which shells) this can be replaced by $PWD
portably?
Thanks,
Ralf
2008-04-10 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS): Move non-XSI
OK to apply? I fail to see why it's necessary to remove these files.
If they existed from a previous compile, they are outdated, so what.
But I may be overlooking something here.
Thanks,
Ralf
2008-04-10 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh
Ralf Wildenhues wrote:
OK to apply?
+# func_xform libobj-or-source
+func_xform ()
+{
+ func_xform_result=`$ECHO X${1} | $Xsed -e s/\.[[^.]]*/.lo/`
+}
_LT_EOF
esac
Did you test this sed expression? Maybe I am testing it wrong?
$ echo ada.ada.ada | sed -e s/\.[^.]*/.lo/
ada.lo.ada
Peter O'Gorman wrote:
Ralf Wildenhues wrote:
OK to apply?
+# func_xform libobj-or-source
+func_xform ()
+{
+ func_xform_result=`$ECHO X${1} | $Xsed -e s/\.[[^.]]*/.lo/`
+}
_LT_EOF
esac
Did you test this sed expression? Maybe I am testing it wrong?
$ echo ada.ada.ada | sed -e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Peter O'Gorman on 4/9/2008 10:19 PM:
| What about eliminating (when progdir='.')
| curwd=`cd . pwd`
|
| Do we know when (with which shells) this can be replaced by $PWD
| portably?
|
| The ones that are not buggy and comply with the
Hello Josh,
can we limit followups to a subset of this impressive array of mailing
lists? Say, to libtool@gnu.org? That would be readable at
http://thread.gmane.org/gmane.linux.debian.devel.general/126905.
Thanks.
* Josh Triplett wrote on Wed, Apr 09, 2008 at 12:34:18PM CEST:
Libtool knows
Many packages use GNU autotools (automake and autoconf) to build, to
the point that ./configure make represents one of the most common
build procedures for Free Software packages. Libraries using
autotools typically use GNU Libtool, partly because it works on almost
any system and partly because
Josh Triplett [EMAIL PROTECTED] - Wed, 09 Apr 2008 03:34:18 -0700
Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
mode.
Excellent, impressive :)))
___
http://lists.gnu.org/mailman/listinfo/libtool
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
Curious: can you please state which Libtool version you timed against,
and if not 2.2.x, redo timing against 2.2.2? Not that I expect wonders,
but I expect something better than what you measured.
I just tested this out on my laptop with
Ralf Wildenhues wrote:
can we limit followups to a subset of this impressive array of mailing
lists? Say, to libtool@gnu.org? That would be readable at
http://thread.gmane.org/gmane.linux.debian.devel.general/126905.
Thanks.
Sure. I assumed that anyone wanting to respond would do so to the
Josh Triplett wrote:
I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
However, when I looked at 2.2.2, it still seems to have a
multi-thousand-line shell script; do you just expect the benefit to
come from the new shell-specific optimizations?
Hi Josh,
There are
* Josh Triplett wrote on Wed, Apr 09, 2008 at 06:02:36PM CEST:
Ralf Wildenhues wrote:
Curious: can you please state which Libtool version you timed against,
and if not 2.2.x, redo timing against 2.2.2? Not that I expect wonders,
but I expect something better than what you measured.
I
Ralf Wildenhues wrote:
That gave the biggest speedup on
GNU/Linux (where forks are relatively cheap).
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7230
This entire message just goes to prove that I do not have a good memory.
I had completely forgotten that you sped up compile mode
On Wed, 9 Apr 2008, Ross Burton wrote:
I realise this isn't libtool 2.2, so I'm willing to believe there are further
speedups.
What I notice from your timings is that libtool 2.1 takes much less
system time than libtool 1.5.26-3 but the user time is quite similar.
The real time is surely
On Wednesday 09 April 2008 03:34:18 am Josh Triplett wrote:
Meanwhile, modern systems such as GNU/Linux have reasonable library
mechanisms, and need relatively little of the machinery in libtool.
On these common systems, it would significantly improve build times to
avoid running that libtool
On Wed, 9 Apr 2008, Josh Triplett wrote:
I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
However, when I looked at 2.2.2, it still seems to have a
multi-thousand-line shell script; do you just expect the benefit to
come from the new shell-specific optimizations?
Since
On Fri, 14 Mar 2008, Bob Friesenhahn wrote:
On Fri, 14 Mar 2008, Vincent Torri wrote:
it's not my patch but here is what I've found:
http://lists.pld-linux.org/mailman/pipermail/pld-cvs-commit/Week-of-Mon-20070226/144657.html
and it's not in the libtool patch list. Should all patches be
On Wed, 9 Apr 2008, Vincent Torri wrote:
It seems that most of this patch is just adding cegcc* to existing case
statements.
Do you think that the patch looks good ? I'm porting more and more libs, and
creating the dll by hand is quite bothering. So i'm planning to works a bit
on how to
Hi Ross,
* Ross Burton wrote on Wed, Apr 09, 2008 at 03:44:40PM CEST:
EDS with libtool 1.5.26-3
real 4m35.934s
EDS with libtool 2.1 (2.1a+cvs1.2525+20071016-1)
real 4m10.648s
EDS with dolt
real 3m40.974s
OK, so we're already half-way there, and the speedup in Libtool 2.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Friesenhahn on 4/9/2008 11:15 AM:
| On Wed, 9 Apr 2008, Josh Triplett wrote:
|
| I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
| However, when I looked at 2.2.2, it still seems to have a
| multi-thousand-line
On Wed, 9 Apr 2008, Eric Blake wrote:
| Since shell scripts are not compiled, the size of a shell script has
| very little to do with its execution time.
On the other hand, recent improvements in autoconf 2.62 proved that we
were able to speed up testsuite performance by more than 10% by merely
Eric Blake wrote:
According to Bob Friesenhahn on 4/9/2008 11:15 AM:
| On Wed, 9 Apr 2008, Josh Triplett wrote:
|
| I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
| However, when I looked at 2.2.2, it still seems to have a
| multi-thousand-line shell script; do you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Friesenhahn on 4/9/2008 7:01 PM:
| There may be value to extracting these shell functions into separate
| files which are sourced only when needed. This way the overhead of
| parsing linking code is not encountered while compiling,
Bob Friesenhahn wrote:
On Wed, 9 Apr 2008, Eric Blake wrote:
| Since shell scripts are not compiled, the size of a shell script has
| very little to do with its execution time.
On the other hand, recent improvements in autoconf 2.62 proved that we
were able to speed up testsuite performance
Bob Friesenhahn wrote:
On Wed, 9 Apr 2008, Eric Blake wrote:
| Since shell scripts are not compiled, the size of a shell script has
| very little to do with its execution time.
On the other hand, recent improvements in autoconf 2.62 proved that we
were able to speed up testsuite performance
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
(using bash)
$ for y in {1..100}; do echo func_notused${y} () { parse.sh; for x
in {1..1}; do echo foo parse.sh; done; echo '}' parse.sh;
done; echo 'echo Done' parse.sh
It seems that the slowest possible shell is selected by default.
Maybe
Bob Friesenhahn wrote:
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
(using bash)
$ for y in {1..100}; do echo func_notused${y} () { parse.sh; for x
in {1..1}; do echo foo parse.sh; done; echo '}' parse.sh;
done; echo 'echo Done' parse.sh
It seems that the slowest possible shell is
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
This is a list off shell functions that appear in the generated libtool
script on my linux system (one of Ralf's patches is applied). Yes, we
could probably move these around some to get func_mode_compile closer to
the top.
The important thing is not
29 matches
Mail list logo
