httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: cvs commit: httpd-test/flood/build apr_common.m4
Date Wed, 27 Mar 2002 00:32:49 GMT
On Tue, Mar 26, 2002 at 04:13:56PM -0800, Aaron Bannert wrote:
> On Tue, Mar 26, 2002 at 09:19:51AM -0800, Justin Erenkrantz wrote:
> > > If it's not installed as part of APR it should be. We shouldn't have it in
> > > our repository merely because we don't want to have to keep them in sync.
> > 
> > It wouldn't make sense as part of the install as it is only needed
> > to build configure.  
> 
> I disagree. You can't have it both ways. If flood, an application that
> depends on an already-installed version of APR, requires some autoconf
> macros provided by APR then those macros must be installed by APR.

Uh, how can an installation of APR provide the macros?  The paths
are hardcoded in flood's configure.in.

To be clear, we're talking about this line in configure.in:

dnl m4 Macros from APR
sinclude(build/apr_common.m4)

We have to have this file when we *generate* configure or autoconf
will die.  We can't rely on installed versions of APR since we
don't know where these are and we have no way of telling autoconf
that.  We also shouldn't have the user change that path to point at
their installed location of APR manually.  Therefore, this file needs
to exist somewhere in *our* tree.

I think you're not understanding the problem here.

httpd will have this problem too.  And, the only way I can see this
happening is to have its own copies of the macros.  httpd-2.0
cheats by enforcing that apr must be in the source tree.  -- justin

Mime
View raw message