On Wed, Feb 28, 2001 at 09:49:09AM -0600, William A. Rowe, Jr. wrote: > From: <[EMAIL PROTECTED]> > 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/
