On Fri, Apr 8, 2011 at 11:29 AM, William A. Rowe Jr. <[email protected]> wrote: > On 4/8/2011 9:07 AM, Guenter Knauf wrote: >> Am 08.04.2011 08:02, schrieb William A. Rowe Jr.: >>> Jeff, I've lost your thread, probably because it's half at httpd. >>> >>> Just so you know, I did get to spend my hours yesterday and today on 2008R2 >>> with Visual Studio 2010 - mostly on the tasks of rebuilding a VM to which >>> I had lost the admin password (damn 'password constraints'). >>> >>> I would like to spend some time tomorrow and Saturday morning wrapping up >>> all our work, I have Steve's work ready to commit and will at least ensure >>> Bert's suggestions are adopted, if not a wholesale fix to //unc/vol issues. >>> >>> Guenter, you have also make a ton of adjustments - are your changes ready >>> to fly? >> Regarding netware: >> yes sir - all builds nicely, and I can now compile NetWare targets on Linux >> for all >> APR/APU and httpd HEAD/2.2.x versions. >> >> Regarding windows: >> I would like to cleanup some stuff in apr: >> http://people.apache.org/~fuankg/diffs/apr_cleanup.diff >> it makes no sense to me that we duplicate HAVE_* in arch/apr_private.h for >> which we have >> already APR_HAVE_* in apr.h[w] ... > > AIUI, Autoconf duplicates these, no? If not, I generally agree, however > you didn't look sideways with this proposal, for example, > strings/apr_strings.c:#ifdef HAVE_STDLIB_H just to name one example. > > And I also wouldn't agree with including process.h to every consumer of apr, > adding new system headers to apr.h needs strong justification. Adding this > under the arch/private generic header would be fine, compilers are fast enough > these days that it shouldn't be a colossal hit on build time.
process.h has a cute history 1.4.x: APR_HAVE defined in apr.hw/apr.h.in; the include is performed in apr.hw if defined so apr.h.in needs to add the include if defined for same app experience with the two build systems trunk: you removed the APR_HAVE_ and include from apr.hw; Günther added the APR_HAVE back to apr.h.in, so they're out of sync and need to be fixed fine with me not to include it everywhere, but the APR_HAVE has been useful (I think httpd uses that) APR_WANT_GETPID for apr_want.h is the more appropriate interface for APR 2, but that still needs a visible APR_HAVE_PROCESS_H
