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: svn commit: r892141 - in /apr/apr/trunk/include: apr.hnw arch/netware/apr_private.h
Date Mon, 21 Dec 2009 17:41:37 GMT
Guenter Knauf wrote:
>> So the older getpassword isn't threadsafe, getpass_r is present, and as I
> I really wonder from what you take this knowledge?

>From commit comments I had inferred it..

> Oh, so this then makes it valid to break it??

I didn't say that.  Refer to the prior commit message when this API was
added, this seemed to be a reasonable assumption.

> Unfortunately it
> turned out that newer NDKs have issues on multiprocessor AMD
> installations which forces me to fall back to an older NDK which doesnt
> have getpass_r.

And I'm glad to learn that.  Reverting now, thanks for clarifying this.

> In addition your other changes = moving header includes into apr.h
> breaks compilation and requires to include apr.h before apr_private.h
> within at least two source files, or to include apr.h in apr_private.h.
> (I admit that I assume this from a mail I got privately with topic 'Does
> Wrowe own APR?', I did not yet test it self).

Sorry that I haven't see such an email, obviously by design.  If the topic
of that email was technical discussion, such as this proposed refactoring
of apu_config.h + apu.h into the apr_put the rivate.h + apr.h, or support for
autoconf vs msvc vs scons, such a discussion would belong on this list.

Including apr.h from apr_private.h would be one such workaround, sure.

> Bill, even when we have CTR with APR its not ok when you touch
> platform-specific files without testing, nor talking with the folks who
> actually care about the affected platform -- nobody else does such, and
> if its expected from me that I compile and test changes if I touch Linux
> or Win32 files I think its only fair to expect same from you too.

Gun, it's impossible in APR for developers to do *anything* and also test
on all platforms.  Nobody here tests on all possible forks of all platforms,
Testing Linux isn't enough.  There is nothing approaching configure-code
coverage testing here.  Breakage is inevitable, and the most we can ask
of each other is a best-effort guess of how to correctly update the code.

But the simple fact is that this is APR 2.0, there are a ton of things
that obviously aren't 'done' yet, such as references to apr-iconv, a lib
that couldn't even be built without apr, or matching windows/netware to
the autoconf/scons configuration results.  In order to move forwards, things
will break.  Should mingw users have a fit when that build is broken, as it
has been since 1.2, or just offer error logs and hopefully patches?

>From my grep of the source tree, the apu.hnw file was never referenced,
so I presume the NWGNUmakefile schema wasn't building apr-2.0 in the
first place ;-?

View raw message