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 ;-?
