apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: 1.x trees broken
Date Fri, 31 Mar 2006 22:58:46 GMT
On Fri, Mar 31, 2006 at 04:31:14PM -0600, William A. Rowe, Jr. wrote:
> Would whoever's contributed to this conundrum please comment why...

that hasn't ever worked afaict, see r356960 in apr trunk :)

The _find macros that are in the respective trunks attempt to fix some
of this problem, but probably need the next minor version bump due to
not searching all of the old paths any more.

> Don't tell me none of the devs have apr installed in some common
> system path for our current development tools, such as svn, and please
> don't suggest that we are expected to push that to the bleeding edge
> just to get an httpd build for testing to an alternate
> /opt/test/httpd-x.x/ path?

If a user builds an arbitrary version of apr, then httpd can be made
link to it, it's just that they have to take responsibility for
configuring and building it. This is in-line with treatment for any
library I guess :)

httpd will only configure a bundled apr for a user if it doesn't find a
suitable version of apr installed already.

I think this is good compromise logic, since the library that httpd
configures will be installed in /usr/local/apache2/, it doesn't matter
that the configure parameters may not be suitable for other applications
which want to use apr, and if httpd finds a usable apr in a system
path - why wouldn't it use it?

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Mime
View raw message