On 5/8/06, Mladen Turk <[EMAIL PROTECTED]> 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.
-garrett
