Re: Avoid using grep in func_lalib_p

[Olly Betts]

On 2008-04-24, Ralf Wildenhues <address@hidden> wrote:
> * Olly Betts wrote on Thu, Apr 24, 2008 at 08:04:03AM CEST:
>> I noticed that the sed and grep combination in func_lalib_p can be
>> folded into a single use of sed.  I don't think this is likely to
>> be a hot spot, but it's an easy fix.
>> 
>> I'm not an expert on sed portability but it doesn't seem to fall afoul
>> of anything in the autoconf manual.
>
> Two things: sed Q is nonportable, it's a GNU extension.

Oops (I did say I'm not an expert!)  That's fixable I think, but...

> Also, proprietary seds typically don't barf with a script of 4q whatever
> their input (binary, really long lines).  We don't like generating
> needless core files.

... I don't see a way around this.

Of course for a known good sed, this approach could be used conditionally, but
that's only worthwhile if func_lalib_p gets called a significant number of
times, so I did a quick from-clean build of Xapian using "-x" and counted the
number of calls to each "func_XXX", and func_lalip_p is never used in this
case.

In case it's interesting, here's the list of functions and how many
times they're called in this build:

      4 func_execute_cmds
     13 func_emit_wrapper
     17 func_generate_dlsyms
     17 func_mode_link
     17 func_verbose
     27 func_show_eval
    134 func_stripname
    159 func_dirname_and_basename
    159 func_lo2o
    159 func_mode_compile
    159 func_write_libtool_object
    176 func_check_version_match
    176 func_enable_tag
    176 func_infer_tag
    176 func_mkdir_p
    222 func_basename
    228 func_lalib_unsafe_p
    228 func_source
    245 func_dirname
    318 func_show_eval_locale
    352 func_opt_split
   1757 func_append
   5867 func_quote_for_eval

> So thanks for the patch, but no, unfortunately not acceptable.

Sure, I understand.

Cheers,
    Olly