At 12:18 PM 7/18/2002, Karl Fogel wrote:
Bill,
- What's the status of the new apr-iconv library?
The new apr-iconv library needs to be taught to consume apr. I'll
do the Win32 work if someone will tackle the build side of Unix.
Note the end app [SVN] shouldn't be aware of it. We need one
more macro, something like APR_HAS_APR_ICONV inside of
the apu_private or apu header.
- What's status on the move of apr_xlate* to apr-util?
Finished, with the exception of the APR_CHECK_ICONV_INBUF
m4 macro that tests for the iconv prototype differences, and one
more hack to use our apr_* namespace protected entry points
from xlate.c if APR_HAS_APR_ICONV is toggled. We also need
that symbol set up in apu or apu_private.
The first macro sticks the #define APR_ICONV_INBUF_CONST 1
into apr_private.h which we don't see inside of apu_private.h, so
we can't pick it up inside of apr-util/xlate/xlate.c.
If someone who groks m4 much better than I would get this inserted
into apu_private.h from apu_private.h.in ... we would be done with the
new unix / using installed xlate problems.
I'm asking for the Subversion Alpha release -- we'll need to know if
we can base the release on HEAD of apr and friends, or if we should
use last Monday's APR and ship the GNU iconv library with our Win32
distributions.
You all know the ASF position on shipping GNU code, just be aware that
will be a fork from any Apache releases. I'm trying to get into a position
where -we- build mod_charset_lite on Win32 and are in a position to ship
that example module.
We'd also been thinking of making an interim release today. It looks
like for that we'd *have* to go with the last-Monday-etc solution
above, right?
Unless our unix problem with APR_CHECK_ICONV_INBUF is fixed, yes.
If that gets fixed, you should be good for cvs HEAD on APR.
Bill
