apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: To tag apr 1.4.3/-util 1.3.11?
Date Fri, 08 Apr 2011 15:29:34 GMT
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?

Mime
View raw message