"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: Which flavor of awk are you using? We strongly recommend the one cited on the 'building_win32' page. DJGPP and GNU awk were both flawed in 3.0.3-3.0.6. You can try manually adjusting that file for valid version tags.
Using some clever macros - we may eliminiate the dynamic creation of VERSIONINFO tags in the coming few weeks - It's already in the incubation/httpd/cli/trunk/mod_aspdotnet/ included version file to generate different flavors of the version token, since we need both comma and period delimited flavors. I'll try backporting this change. About your static build - it sounds somehow fatally flawed. I will try to reproduce; note we use VC6 for our dev, test and release, usually. I've used the VC6 built apr in 2003 studio projects, but haven't tried building on 2003 studio in a while.
Thanks for your reply.
I am using the awk.exe from Brian Kernighan's site as recommended. It's the only awk.exe on my hard drive.
The results I showed were using MSVC++ 6.0, but I have also tried MSVC++ .NET 2003, and it produces the same errors: C compiler errors on "xlate.c" while building apr-util (in both static and dynamic libraries), and failure to generate the VERSIONINFO in the DLL builds.
Did I do the right thing in renaming the unzipped directories (removing the "-1.0.0" suffix)? That seemed necessary before the .dsw workspace would even open properly.
I haven't tried hacking the VERSIONINFO, because I'm happy with the static apr.lib for now; I don't need aprutil.lib or the DLLs quite yet.
I'm just trying to provide useful feedback to help you resolve problems with the distribution -- at present I'm not blocked.
Keep up the good work -- APR is very useful and is making my project a lot easier. I'm using it from C++, and have wrapped what I use inside my own C++ classes, but I appreciate APR's low-level C architecture -- in fact I chose it over many alternative portability layers because I think you guys got the design choices right. (At Netscape we used NSPR, which all in all I'm glad you didn't perpetuate.)
Currently I am trying to rewrite the std C++ operator new and operator delete to use APR memory pools -- with per-thread selection of the current pool -- so 'new' will "just work" with a pool per thread. The idea is to supply the pool argument as thread context somehow, rather than explicitly. It's kind of challenging to figure out how to do this efficiently enough, given the high frequency of 'new' and the costs of threadkey access. It's an interesting design problem and quite important for multithreaded C++ programs, although it doesn't matter if C is your language.
One other thing I miss is a bit more documentation on APR -- beyond the autogenerated API descriptions. Is anyone working on a book? Or just a few more HTML files? It's a bit hard to determine the semantics and usage of some of the APIs. To someone who wasn't part of the developer community that wrote APR, puzzling out exactly what each API is for, and how you use it, from such minimalist doc as a list of function calls and their parameters is challenging, even if you are familiar with the underlying platform-specific APIs they are obviously based on.
As a doc substitute, I find greping this mailing list doesn't seem to help as much as I hoped it would, e.g. when I can't tell what the difference is between apr_threadkey_data_get() and apr_threadkey_private_get() from the doxygen pages. I usually end up having the read the .c source, which is educational, I suppose, but it slows me down.
Compared to more mature libraries (Berkeley DB comes to mind, because I use that also) the APR doc is, well, still almost absent. Good or bad API doc is a large part of why libraries get used successfully or don't, IMHO. I realize this is just a matter of time.
BTW I'd be happy to review / help edit any in-progress API documents that anyone might be working on.
