apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Christie" ...@sover.net>
Subject Re: Win32 project building
Date Sun, 14 Nov 2004 19:16:04 GMT
> "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.

View raw message