On 4/27/07, demerphq <demerphq@gmail.com> wrote: > On 4/26/07, demerphq <demerphq@gmail.com> wrote: > > On 4/26/07, Jerry D. Hedden <jdhedden@cpan.org> wrote: > > > On 4/26/07, Rafael Garcia-Suarez wrote: > > > > On 26/04/07, Jerry D. Hedden wrote: > > > > > Seems to have been fixed by 31085. > > > > > > > > But now t/uni/folds.t fails for me. > > > > > > Me, too. > > > > Dont worry. Ive got it under control. Patch will be ready when its > > baked. Currently its still in the mixing bowl. :-) > > Attached is a new patch that should fix things. It includes a pretty > much completely rewritten and much more flexible regcharclass.pl, > which in turn means a new regcharclass.h. > > The updated patch passes all tests on my machine. This time I > doublechecked, then had some coffee and checked again. :-) > > I really have no idea what happened before, theres obviously no way I > could have run a full test with the previous patch, yet I'm sure I > did. The only thing i can think of is that I ran it in the wrong > directory due to stupidity and didn't notice. :-( > > Anyway, sorry for the breakage folks, your regular service should > resume with this patch. > > Oh, I updated the win32 Makefile to automatically regen regcharclass.h > when Porting\regcharclass.pl has changed, and established a dependency > from regcomp.obj and regexec.obj to regcharclass.h and regnodes.h > (which is itself dependent on regcomp.sym), this ensures that the > right things are rebuilt if any of the regex engine config data has > been updated. As usual I've punted on modifying the other makefiles. > (Not sure if its relevent to anybody that isnt directly hacking on the > regex engine anyway.) Actually, im not much of a makefile hacker so > its possible they arent quite right. They seem to work fine here tho. Sigh. Third time lucky as they say. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next