apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Move apr_xlate from apr-util to apr-iconv?
Date Mon, 30 May 2005 14:41:45 GMT
Jeff Trawick wrote:
 > On 5/30/05, Mladen Turk <mturk@apache.org> wrote:
 >>Of course the other option is to disable apr_xlate by default if
 >>either iconv or apr-iconv is not found.
 > What is the problem to solve here?
 > a) apr-util doesn't guarantee that all APIs are present on all builds 
of APR
 > b) apr-util may depend on more than just libc+apr
 > c) Windows build of apr-util forces you to bundle apr-iconv even
 > though you may not care about apr_xlate, unlike the Unix build
 > For a) and b), these are wide-spread issues, and the current state has
 > been considered a reasonable compromise thus far.

I'm not speaking about particular features like OS or libc differences.
Take for example xml or dbm support. For both things there are bundled
sources inside apr-util distribution itself.

 > For c), consider how to fix the apr-util build on Windows so that if
 > there is no system iconv and no apr-iconv, then everything builds with
 > appropriate feature set without somebody having to manually change
 > some flags in apu.hw.

That's fine, I can do that.
But in that case the xpr_xlate api either must provide a dummy char copy
or it must be considered as an optional apr-utils component, something
like APR_HAS_THREADS for example.


View raw message