On Sat, May 29, 2010 at 7:25 PM, William A. Rowe Jr.
wrote:
> Is your thinking to use a find_ap[r|u] setup that can resolve either/or
> at ./configure-time?
Yes.
> Since we've acknowledged that apr/apu are hand-in-hand with 2.0, does it
> make sense to merge these and distribute both, or to teac
On Sat, May 29, 2010 at 7:39 PM, Sander Temme wrote:
> Wouldn't we rather move to a construct where APR is not needed to buildconf?
> If all we're doing is copy in find_apr.m4, can't we just fork that and allow
> it to evolve into our own idea of finding an appropriate APR against which to
> c
On May 29, 2010, at 6:36 PM, Justin Erenkrantz wrote:
> I would like to go commit the following to apr and httpd trunk.
>
> I don't think it is appropriate for the local buildconf-time
> environment to make it impossible at configure-time to use an older
> APR configuration. Restoring find_apu.
On 5/29/2010 8:36 PM, Justin Erenkrantz wrote:
> I would like to go commit the following to apr and httpd trunk.
>
> I don't think it is appropriate for the local buildconf-time
> environment to make it impossible at configure-time to use an older
> APR configuration. Restoring find_apu.m4 to apr
I would like to go commit the following to apr and httpd trunk.
I don't think it is appropriate for the local buildconf-time
environment to make it impossible at configure-time to use an older
APR configuration. Restoring find_apu.m4 to apr trunk resolves this
issue for me. (I'm leaving the ifde
