Re: make libtool faster v1

[Gary V. Vaughan]

Hi Ralf!

Ralf Wildenhues wrote:
> So, to get to my point:  Would the others accept speedup patches?

Except where they obfuscate the code.

> For now, it has a
> drawback: it depends on the user not using stdin (e.g., in conjunction
> with a `-' argument somewhere).  Do we support this mode?

Nothing is documented, and I can't think why anyone would want to
feed objects to libtool on stdin.  It's probably worth a NEWS entry
though, incase someone has found a way to talk to libtool on stdin.

> The patch below is against HEAD, though I'd really like to backport to
> branch-2-0 and branch-1-5 as well.

branch-1-5 is stable at the moment, so only bug fixes can go there.
branch-2-0 is not quite stable yet, but I suspect there will be
shouting if we perturb the code enough to force retesting... well,
we need to retest everywhere when the outstanding bugs are fixed
anyway, so backporting to branch-2-0 isn't necessarily out of the
question.

> +func_lalib_unsafe_p ()
> +{
> +    lalib_p=no
> +    if test -r "$1" && exec <"$1"; then

I'd be amazed if this exec has any portability problems.

> +     for lalib_p_l in 1 2 3 4
> +     do
> +         read lalib_p_line
> +         case "$lalib_p_line" in
> +             \#\ Generated\ by\ *$PACKAGE* ) lalib_p=yes; break;;
> +         esac
> +     done
> +     exec <&-

The old syntax for this was simply 'exec <&', but I'm not sure
which (if any) might cause problems with some shells.  However,
since we are saying that stdin is not used by libtool, then it
should be safe to drop this line anyway.  Maybe for safety it
would be best to use exec</dev/null?  Whichever, a big comment
explaining what the optimisation is, and how it works is definitely
needed.

> -     func_lalib_p "$file" \ ||
> +     func_lalib_unsafe_p "$file" \ ||
>         func_fatal_help "\`$lib' is not a valid libtool archive"

        func_lalib_unsafe_p "$file" || \
           func_fatal_help "\`$lib' is not a valid libtool archive"

(my comments about linesplitting around || and && notwithstanding)

The rest looks fine to me.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature