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

[Peter Rosin]

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"
}

into:

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?

Cheers,
Peter