apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject AntĀ build, Borland C++, apr_file_flush, non-portable random methods in apr-util/test
Date Thu, 10 Feb 2005 15:30:54 GMT
I've created Ant build files for APR, APR-util and APR-iconv to support 
the Ant build for log4cxx.  The files are available from the Apache CVS 
as logging-log4cxx/apr-build.xml, logging-log4cxx/aprutil-build.xml and 
logging-log4cxx/apriconv-build.xml.  They are reasonably full featured. 
  So far, I've tested them with Microsoft C++, Borland C++ on Windows 
and gcc on Mac OS/X and Linux.  These build files require the CVS HEAD 
versions of ant-contrib and cpptasks from 

I'm primarily testing the build file as driven from the log4cxx build 
file, however they should be useful by themselves if copied into the 
root directory of the appropriate project and renamed to build.xml.  
The build files also run the unit tests, however several seem to be 
failing on Windows.  I have not yet enabled the build files to generate 
IDE project files, but that will occur fairly soon.

I've attached the patches that I needed to make to get APR compiling 
with the Borland compiler to 

The apr-util/test/testdate.c and testrelist.c do not link on Windows 
due to the use of non-portable random methods that I assume could be 
replaced by methods from apr_random.  testdate.c also uses the LL 
suffix for 64-bit integers instead of using APR_INT64_C.  I've logged 
this as http://issues.apache.org/bugzilla/show_bug.cgi?id=33491.  
Currently the Ant build file skips building these tests.

I've also logged a bug on apr_file_flush on Windows 
apr_file_flush on an unbuffered file on Windows is vastly more 
expensive than the same operation in the Unix and OS/2 implementations. 
  On log requests where apr_file_flush was called immediately after 
writing on an unbuffered file, the Windows implementation was a 100x 
slower than the same test where apr_file_flush was not called due to a 
call to very expensive call to FileFlushBuffers.  On Linux, there was 
not noticeable difference in performance since the same operation is a 
no-op.  I've reworked log4cxx to avoid the issue, but it does appear to 
be a landmine that could catch unsuspecting developers.

View raw message