On Fri, Apr 8, 2011 at 10:07 AM, Guenter Knauf <fua...@apache.org> 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] ...
trunk or 1.4.x? (your patch looks like trunk) as for 1.4.x: APR_HAVE in apr.h* is an API; can't add new ones in 1.4.x series (but if 1.4.x/include/apr.h.in is missing something for Windows that has been in apr.hw, that's fair game since apr.h.in has never been reasonably close to correct for Windows) as for trunk: start a new thread not related to getting 1.x releases out the door ;) > > and comments on that? > > 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 :-( is this a 1.4.x discussion?
