[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13472: [PATCH] libtool: speed up by pre-cutting sed's input by dd

From: Peter Rosin
Subject: bug#13472: [PATCH] libtool: speed up by pre-cutting sed's input by dd
Date: Thu, 13 Feb 2014 18:57:21 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 2014-02-12 16:22, Nick Bowler wrote:
> On 2/11/14, Peter Rosin <address@hidden> wrote:
>> Ok Pavel, first of all, sorry for the "smallish" delay in handling
>> your request, and Nick, are you able to test this patch?
> [...]
>> Does my version work? The testsuite behaves OK for me, but other than
>> that I haven't tested.
> Patch seems to work!

Ok, everybody seems happy. But not me, not 100% anyway. This introduces
an extra fork, and AFAICT, the "extra protection" is only needed when
func_lalib_p is called from func_ltwrapper_script_p. Should we perhaps
have a separate implementation in func_ltwrapper_script_p instead of
simply calling func_lalib_p?

Maybe we could also lose the "sed -e 4q" part when dd limits the size?

I.e. keep func_lalib_p as before:

func_lalib_p ()
    test -f "$1" &&
      $SED -e 4q "$1" 2>/dev/null \
        | $GREP "^# Generated by .*$PACKAGE" > /dev/null 2>&1

but change func_ltwrapper_script_p from:

func_ltwrapper_script_p ()
    func_lalib_p "$1"


func_ltwrapper_script_p ()
    test -f "$1" &&
      $lt_truncate_bin < "$1" 2>/dev/null \
        | $GREP "^# Generated by .*$PACKAGE" > /dev/null 2>&1

where lt_truncate_bin is either "/usr/bin/dd bs=4096 count=1" or
"$SED -e 4q" depending on the presence of a suitable dd.

That way we shave off a fork, which can't be bad...

Thoughts? Or should I just push out the prior patch?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]