httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: packaging libapreq2 as a dependency
Date Fri, 27 Apr 2012 05:55:22 GMT
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

Mime
View raw message