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
http://ant-contrib.sourceforge.net.
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
http://issues.apache.org/bugzilla/show_bug.cgi?id=33490.
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
(http://issues.apache.org/bugzilla/show_bug.cgi?id=33485).
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.
