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
