This series is just a split-up version of the following patch, for
better readability:
http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00156.html
Pushed already, since the original was posted for review almost 2
weeks ago.
* libtoolize.m4sh (require_Makefile_inc_filter): Rename
* libtoolize: Restore asciibetical order, so that all the
filter function definitions are together.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
libtoolize.m4sh | 242 +++---
1 files changed, 121 insertions(+), 121 deletions(-)
diff --git
On 28 Nov 2011, at 21:44, Bob Friesenhahn wrote:
On Mon, 28 Nov 2011, Peter Rosin wrote:
My typical use case is mid-sized at a magnitude or so larger, and
even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't
be too harsh with a couple of extra forks - a minutes or so on
Pushed as obvious.
* bootstrap (func_require_buildreq_autobuild)
(func_require_buildreq_automake): Vi's delete word command is
too greedy and also eats trailing whitespace before following
non-word-chars. Put back the spaces it ate so that
syntax-checks pass once again.
Signed-off-by: Gary V.
Applied as obvious.
* m4/libtool.m4: Reverse argument order to eliminate spurious
leading X's.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
m4/libtool.m4 |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 0eef323..9c2574f 100644
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features
Applied as obvious.
* tests/demo-noinst-link.test (func_save_files): set the restore
trap outside a function, otherwise AIX 5.3 /bin/sh will run the
trap at the end of the function, instead of when the script
exits.
* tests/demo-relink.test (func_save_files): Ditto.
* tests/depdemo-relink.test
On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts
Hi Peter,
On 8 Dec 2011, at 20:40, Peter O'Gorman wrote:
On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on
Hi Eric,
On 8 Dec 2011, at 19:56, Eric Blake wrote:
On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on
Applied as obvious.
Aside from Apple grep silently failing to run this test and
report violations, libtool still uses non-gnulib versions of
dirent.h and argz.h which use the same macros, but are not
always-defined.
* cfg.mk (local-checks-to-fix): Move
sc_prohibit_always-defined_macros from
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that way and ditch the host check. Thanks!
Is the
On 12/08/2011 08:04 AM, Bob Friesenhahn wrote:
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on
On Thu, 8 Dec 2011, Peter O'Gorman wrote:
Any additional forks will slow down the script and should be avoided on all
platforms.
I definitely agree with that. Besides the Windows problem, it does
not seem like fork performance improves linearly from adding processor
cores so it is
On 12/08/2011 08:29 AM, Charles Wilson wrote:
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By
On 12/8/2011 11:22 AM, Eric Blake wrote:
On 12/08/2011 08:29 AM, Charles Wilson wrote:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
Umm, dash has XSI features (where XSI features covers things like
${var##prefix}). ... Meanwhile, libtool is using more than just XSI
On 12/08/2011 09:29 AM, Charles Wilson wrote:
Has anybody done a comparison between:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI)
to see which is better?
Because I installed mingw32 yesterday on my
18 matches
Mail list logo
