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.

Regards,
Mladen.


Mime
View raw message