On 27/04/2012 05:12, Joe Schaefer wrote: > Now that some time has passed since Philip brought > apreq2 into trunk it's probably a good time to discuss > how best to incorporate it into httpd itself. Right > now the library files are in server/ which basically > means we're internally compiling libapreq2 into httpd. > > Personally I'd prefer to see libapreq2 bundled as an > upstream dependency, ie put the library into an associated > deps package or just something in srclib/ so it will > provide an independent library file (static, dynamic, or both) > so all users including httpd can link to that object. The > apreq devs spent a considerable amount of time writing > the apreq module api so people could use apreq in any > C context- within an httpd module, a CGI script, or an > fcgi daemon. It'd be nice to preserve that flexibility > going forward. > > Anyway I'm certainly willing to work on libapreq's build system > so it will not be dependent on apxs- it should be really easy > to do given that we just need apxs in a very limited way (basically > to get at the apr-*-config package scripts), I > just need to make the apache2 module build optional so just > the library gets built. That would entail pulling the apreq > source files out of server/ and just leaving the apreq2 > filter module as part of httpd's build system. > > +0
I'm +1 for splitting and putting apreq2 filter in the build system; it's what to do with libapreq2 that holds me back... I don't like the idea of "yet another library/dependency" for building httpd, but after thinking about it, I probably wouldn't want it as more clutter either in APR or in libhttpd either. I'd likely change that to a +1 on the whole if I had even a whisper of a rumor if anyone (other than the mod_perl folks) was planning on incorporating apreq into some existing software to justify it being a standalone library. I know we built for it, but I've yet to see real adoption. Issac
