On Wed, Feb 28, 2001 at 09:49:09AM -0600, William A. Rowe, Jr. wrote:
> From: <gstein@apache.org>
> Sent: Wednesday, February 28, 2001 9:14 AM
>
>
> > gstein 01/02/28 07:14:50
> >
> > Modified: xml apr_xml.c
> > Log:
> > enable building against old/new expats
> >
> > Revision Changes Path
> > 1.18 +6 -3 apr-util/xml/apr_xml.c
>
> > +#include "apu_config.h"
>
> May I ask a loaded question? Are we creating apu_config.h on the fly, or are we
> simply missing an apu_config.h.in (which I'm happy to parallel)?
We were missing an apu_config.hw, which I've now checked in. buildconf.sh
calls autoheader, which creates apu_config.h.in for us, then configure
creates apu_config.h. Just like APR's include/arch/unix/apr_private.h.in.
[ APR (Win32) avoids the .hw by putting the header in include/arch/win32;
Apache avoids it by avoiding an include of ap_config_auto.h; we are now
using the autoheader output in apr-util, so the right magic wand needs to
be waved. ]
My fault for not creating apu_config.hw when the file first started to
appear. We weren't truly using it until last night, so we didn't catch its
missing-ness on Win32 until just now.
> We have somehow avoided on-the-fly generation all this time with .h.in files.
> These are easy to mirror on any platform, whether the platform supports build sh
> scripting or not. This is not the case with sh generated scripts.
>
> Can the new header be expressed in terms of an .h.in (.hw, or whatnot by platform)
> or are we departing for the apache-way?
apu_config is built the same as other modules. No departure.
However, I do see some simplification in httpd that we can do...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
|