pcreposix, detect, use by default

[Ken Murchison]

Bron Gondwana wrote:
> On Tue, Sep 11, 2007 at 10:02:50AM +1000, Bron Gondwana wrote:
>> On Mon, Sep 10, 2007 at 02:38:07PM -0400, Ken Murchison wrote:
>>> A lot of the patches (past and present) have been implemented.  Some of the 
>>> others will be implemented in time.  Others may not.
>> Some of them are still waiting for me to finish polishing them as well!
>> In particular the pcreposix patch.
> 
> As promised, here it is.  I'm nearly home, so I'll put it online
> when I'm connected again.  I've reorganised our patchset to put
> the two patches I want to push directly to you up the top (after
> the accepted/upstream ones) for minimal fuzz against CVS.

How about this alternative?  On my dev box the regex functions appear to 
be built in to glibc, so I can't fully test this.

--- configure.in.~1.297.~	2007-08-15 13:22:11.000000000 -0400
+++ configure.in	2007-09-11 12:20:58.000000000 -0400
@@ -243,9 +243,10 @@
  	AC_PROG_LEX
  	AC_CHECK_LIB(fl,main)

- 	AC_SEARCH_LIBS(regcomp, rx regex, [
- 			AC_DEFINE(ENABLE_REGEX,[],[Do we have a decent regex library?])
-		 	AC_CHECK_HEADER(rxposix.h, AC_DEFINE(HAVE_RX,[],[Do we have 
rxposix.h?]))])
+ 	AC_SEARCH_LIBS(regcomp, pcreposix rx regex,
+ 			[AC_DEFINE(ENABLE_REGEX,[],[Do we have a decent regex library?])]
+		 	[AC_CHECK_HEADER(pcreposix.h, AC_DEFINE(HAVE_PCREPOSIX,[],[Do we 
have pcreposix.h?]),
+				[AC_CHECK_HEADER(rxposix.h, AC_DEFINE(HAVE_RX,[],[Do we have 
rxposix.h?]))])], [], -lpcre)
    		

  	SIEVE_SUBDIRS="${SIEVE_SUBDIRS} $sievedir"



> 
> P.S. have you seen the way that patches are "patchbomb"ed to
> the Linux kernel mailing list, and do you think that would
> make sense for this list?  Basically you get:
> 
> Subject: PATCH [0/N] FastMail.FM Cyrus Patches
> Subject: -> PATCH [1/N] dbtool-transaction - Make dbtool use a transaction
> Subject: -> PATCH [2/N] pcreposix - Use PCRE posix-compatability library for regex handling
> Subject: -> PATCH [3/N] actionstring - Remove sieve action string
> 
> Etc - with all the additional patches being replies to the header email.
> 
> Each patch can then start its own separate discussion, and people with
> threaded email readers can easily follow the conversations (or ignore
> ones that they aren't interested in)
> 
> If anyone is interested, I'm happy to bomb our patches here so we can
> discuss them all individually - especially I'm interested in polishing
> comments!

I'm fine with this.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University