apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Move apr_xlate from apr-util to apr-iconv?
Date Mon, 30 May 2005 19:41:22 GMT
On 5/30/05, Mladen Turk <mturk@apache.org> wrote:
> 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.

apr-iconv is relatively big
apr-iconv is not needed on many platforms anyway since system iconv is suitable
many users of apr-util can do without the feature anyway

given all that, why bundle it?

>  > 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.

you mean, like APR_HAS_XLATE?

View raw message