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 fr
* libtoolize.m4sh (require_Makefile_am_filter)
(require_ltdl_mk_filter, require_aclocal_m4_filter)
(require_configure_ac_filter): Rename these functions from this...
(require_filter_Makefile_am, require_filter_ltdl_mk)
(require_filter_aclocal_m4, require_filter_configure_ac): ...to
this, respective
* libtoolize: Restore asciibetical order, so that all the
filter function definitions are together.
Signed-off-by: Gary V. Vaughan
---
libtoolize.m4sh | 242 +++---
1 files changed, 121 insertions(+), 121 deletions(-)
diff --git a/libtoolize.m4sh
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
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. Vau
Applied as obvious.
* m4/libtool.m4: Reverse argument order to eliminate spurious
leading X's.
Signed-off-by: Gary V. Vaughan
---
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
--- a/m4/libtoo
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 t
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 (fu
Applied as obvious.
* tests/demo/foo.h, tests/pdemo/foo.h: Spell `snippet' correctly.
Reported by Stefano Lattarini.
Signed-off-by: Gary V. Vaughan
---
tests/demo/foo.h |2 +-
tests/pdemo/foo.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/demo/foo.h b/tes
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 script
Hi Eric.
On Thursday 08 December 2011, Eric Blake wrote:
>
> Instead of doing it this way, I'd almost rather see:
>
> if test "${BASH_VERSION+set}" = set; then
>
> although if cygwin ever follows debian's lead of using dash for faster
> /bin/sh, I'm not sure if there is a reliable forkless way t
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 windows.
By assuming that windows will run shell scripts on s
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 buil
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
On 12/08/2011 08:03 AM, Gary V. Vaughan wrote:
Any additional forks will slow down the script and should be avoided on all
platforms.
Agreed.
Following up just because "slow down" is not a number:
touch a.c
time (for x in {1..100}; do ./libtool --mode=compile --tag=CC gcc -c -o
a.lo a.c;
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 here..
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 pat
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 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 importan
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.
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 X
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 rar
23 matches
Mail list logo
