Re: restructure patch for review [bug-grep]

[Claudio Fontana]

> > lib/ should be really updated. 
> > I've encountered trouble with modules 'error' (big
> > trouble) and 'savedir' too.
> > 
> > I will post the savedir fix I have made separately
> > too,
> > until lib/ is updated.

I should correct myself here. Updating lib/ might not
be so easy at least for savedir, since the savedir
proto has been changed for grep (ChangeLog entry
2001-02-16  Alain Magloir) to take two additional
parameters (for exclude/include).

I would suggest against keeping the "patched version"
of savedir in lib/ (with a different proto), because
it leads to the confusion we're experiencing now (it
it the gnulib savedir?), and instead (to keep speedup
advantage) suggest a custom savedir_exclude() similar
to current savedir to put in src/ instead of lib/

For changes to savedir required to extend exclusion
and inclusion to directories, see patch for bug
#11017.

I would second the need for info on gnulib "default"
usage. I only have this info from README in the gnulib
source package:
"
We will be developing a testsuite for these
applications.  The goal is
to have a 100% firm interface so that maintainers can
feel free to
update to the code in CVS at *any* time and know that
their
application will not break.  This means that before
any change can be
committed to the repository, a test suite program must
be produced
that exposes the bug for regression testing.  All
experimental work
should be done on branches to help promote this.
"

So this would again point against custom savedir
modifications, because updating gnulib from cvs does
break grep.
 
> > To be able to set search options in grepopt.c
> though I
> > would need an interface to your search struct
> > (search.h) to set matcher, match_*, eolbyte.
> 
> Yes.  There are two possibilities here:
> 
>   -- you have direct access to the variable that
>      would be of my "struct match_spec" type, or
> 
>   -- you also put them in your "struct
>      grepopt" o variable and src/grep.c does
>      the copying/adaptation from there to a
>      "struct match_spec" variable.

I agree to the second. Just a thought: instead of
handcrafting the struct in grep.c directly, we could
call an initialization function you expose, something
like init_search(params); params are exactly (or built
from) the options I keep in o. Just for the eye.

> Maybe I should also rename "match_spec" to
> "search_spec" to correspond to the file name
> before even publishing a first version.

Seems nicer.

> > I see a priority
> > in going for a heavy restructure to make grep more
> > maintenable, and is what I am offering my help
> > for.
> 
> Yes.  I support this fully,

I'm so glad to hear that.

> but since it can
> be quite an undertaking maybe there should be
> an interim 2.5.2 release just to get some known
> and easy bug fixes out the door while the rest
> would go in a 2.6.0 (or even a planned sequence
> of 2.6.*).

It would be so nice to start 2.6.0 with a clean new
design.

> In addition to our respective work, the current
> Red Hat performance-enhancing patches seem to
> be non-trivial as well.

Ah, why are those patches been kept separate from
those in savannah?
Where can I get a comprensive list of those, and how
are they related to patches in savannah?




                
___________________________________ 
Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, 
Giochi, Rubrica… Scaricalo ora! 
http://it.messenger.yahoo.it