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. > oh, and another bad thingy I found with APR on Windows is that ugly > redefining of all the > SIG* defines in apr_private.h - it simply doesnt work as it should, that > means it only > depends on the order of includes: > if signal.h is included before apr_private.h then the wanted redefine > happens, the other > turn signal.h defines win which is not what is desgined as I guess; I found > this with > OpenWatcom which does not allow redefining macros ... (at least not with > different values) > any idea how to workaround this issue properly? > I think that the only clean way would be to define our own APR_SIG* macros > and use these, > but that would then affect all platforms :-( Which could happen with 2.0 but not 1.x - anything more specific about how to avoid these collisions/load order issues for 1.x?
