Nasty configure behaviour

[Brian Havard <br...@kheldar.apana.org.au>]

I've run into this on both OS/2 & linux now. If you have apache2 installed
in /usr/local/apache2 or the apache2/bin directory is PATHed, the
APR_FIND_APR autoconf macro finds that in preference to the version in
srclib/apr. If the former is an old version Apache's build fails. I had
2.0.36 installed & trying to build HEAD died because it couldn't find
apr_strmatch.h (the include paths were pointing to my 2.0.36 source).
Shouldn't the bundled apr/apr-util always be used first?

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------

Re: Nasty configure behaviour

[Justin Erenkrantz <je...@apache.org>]

On Fri, May 17, 2002 at 01:09:55AM +1000, Brian Havard wrote:
> I've run into this on both OS/2 & linux now. If you have apache2 installed
> in /usr/local/apache2 or the apache2/bin directory is PATHed, the
> APR_FIND_APR autoconf macro finds that in preference to the version in
> srclib/apr. If the former is an old version Apache's build fails. I had
> 2.0.36 installed & trying to build HEAD died because it couldn't find
> apr_strmatch.h (the include paths were pointing to my 2.0.36 source).
> Shouldn't the bundled apr/apr-util always be used first?

No.  But, what we can do is when there is no --with-apr value
specified, we can change it so that we prefer the bundled copy
instead.

I just checked in some changes so that the user of APR_FIND_APR
macro must explicitly permit searching for installed locations if
there is no --with-apr, --with-apr-util macro given to configure.

As I said in the commit log, it may be possible to revert this and
only ignore locations that are our prefix.  That's another way,
but the approach I committed seems more conservative.  -- justin