Re: --with-included-foo={yes,no} and which foo.h to use?

[Stepan Kasal]

Hello Charles,

On Thu, Jul 07, 2005 at 02:33:59AM -0400, Charles Levert wrote:
> * On Tuesday 2005-06-28 at 13:03:21 +0200, Stepan Kasal wrote:
> > I think we should support them; the configure option
> > --with-included-regex (misnamed, but already established) should be
> > there.
> 
> So do I.

Good.

> > I thought that we should upgrade to glibc regex in 2.6 branch.
> > We should release other fixes in 2.5 branch before.
> 
> But there's a catch-22 here.  See below.

I don't understand exactly why the number is 22...

> Updating to glibc's regex.c will allow us to
> progress in fixing RE_ICASE bugs now, and maybe
> others as well.  That why I can't see one being
> a priority without the other.

Well, it's obvious that with the old regex.c we cannot fully fix all
the icase problems.  We can just fix the most obvious.

Full icase fix is tied to new regex.

But there is no need to fix _all_ problems in the _next_ release.
I wanted to create an improved version of 2.5.1, which would be ready
for people which for some reason cannot use the new regex.c.
(Perhaps the new regex won't compile on an ancient platform, or they
will have to use a regex which shows the inefficiency of the new
regex, perhaps something like the original palindrome regex, which
takes ages to run with new regex.)

In short, I wanted to squeeze maximum from the old regex before we
move to new regex.  I think that the new regex might open a can of worms.

I hoped to achieve this with minimal effort, just by ordering the patches.
But in some cases, like interaction of -i with --color or -o, there
seems to be an extra work, which will be dropped after we move to the
new regex.

So my opinion still is that it would be better to release what we have
now as 2.5.2, no matter how many bugs are remaining.

But, of course, your vote should have more weight than mine, as you did
more work.

Stepan