> "William A. Rowe, Jr." <wrowe@rowe-clan.net> 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.
|