apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: Moving apr_xlate from apr-util to apr-iconv
Date Mon, 08 May 2006 17:46:33 GMT
On 5/8/06, Mladen Turk <mturk@apache.org> wrote:
> Garrett Rooney wrote:
> >>
> >>  From the users point of view noting will change, except that
> >> the apr_xlate will reside in a different .so.
> >
> > In that case I still think it's a bad idea, there's no change other
> > than requiring those users to download a huge amount of code they
> > don't actually need because all they want is the wrapper functions
> > that call through to the system iconv.
> >
> Well, users are downloading the code they don't need already.
> For example, if I'm building win32/win64 code, why do I need
> all that 'unix' source files. Not to mention the expat, etc.

Oh please.  That's totally not the same thing.

> If your only concern is the size of apr-iconv, then I think
> you have a wrong 'concern'.
> IMHO the dependency should be straightforward:
> 1. apr can be used as standalone.
> 2. apr-util can be used as dependent of apr only.
> 3. apr-iconv can be used as dependent of above.
> That should be the fact for ALL platforms.

I have no objection to moving towards a system where APR-Util doesn't
link in all sorts of external dependencies (although I think iconv is
the least of our worries here, dbd and dbm are far worse), but even
then I would object strongly towards lumping apr-iconv and apr_xlate
together.  The current system where apr_xlate can OPTIONALLY use
apr-iconv is just fine in my opinion.  See wrowe's mail for a
perfectly reasonable take on the subject.


View raw message