apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: Is --enable-utf8 working everywhere?
Date Wed, 17 Jul 2002 03:42:24 GMT
William A. Rowe, Jr. wrote:

> At 09:37 PM 7/16/2002, Brane wrote:
> Can we start from the top here?
>
>>> What iconv sources are you planning to build?  From where?
>>
>>
>> I did say I was using the libiconv-1.8 sources. It's from www.gnu.org.
>
>
> Ok, one to three problems here.
>
> First, apr-iconv is from BSD - it's not under gnu license.  Are we
> planning to distribute it with sources?  As binaries?  This is dripping
> into muddy waters.  And this with a project that claims the ASL isn't
> even a compatible license.


We're not planning to distribute anything. My patch only adds for 
Windows something that we've been "providing" on Unix for ages -- 
namely, support to let the _user_ link apr with libiconv. On Unix, it's 
in the configury; on Windows, it must be done some other way.

> But it becomes hugely mucky waters if you start building our library
> with their library.  They are pretty clear (assuming this is LGPL) that
> other apps can link to it.  But other libraries?


Not our problem. The LGPL only kicks in if we _distribute_ the libiconv 
sources, which we don't/won't.

> Second, we're invested in apr-iconv, most of the porting effort was 
> done...
>
>>> The apr-iconv port in-progress?
>>
>>
>> Not yet.
>
>
> Sad that we aren't investing the effort here.  But there was the .dll
> tangle, apr-iconv needing apr, but apr being built upon iconv.
>
> The only thing that needed it, according to my grep of apr_xlate*,
> was md5.  That just moved.  iconv is next.  Expect minor breakage
> for just a bit.  Then we can include apr-iconv between building apr
> and building apr-util.  In fact, my preference is to build apr-iconv
> as apr-util/xlate/iconv/... much like /xml/expat.


Sure, I'm all for that. But, notice that even getting apr-iconv building 
correctly on Windows would take more time than it took me to support 
libiconv. Like I said, we _need_ this for Subversion Alpha, in two days' 
time. I don't think I could get apr-iconv into shape by then. (I notice 
it relies on symlinks for charset aliases -- bah!)

> I don't intend to break the ability to link to an installed local iconv.
> This is a -supplement- for those who don't have an iconv handy.


There's no such ability on Windows today, and my patch touches nothing 
else (I hope).

>>> Am I misinterpreting that this is a dummy module?
>>
>>
>> Yes and no. If you don't have the libiconv sources, it creates a 
>> dummy (empty) iconv.lib and doesn't define APR_HAS_XLATE, etc. That's 
>> because of MSVC project file idiosyncracies.
>
>
> I'm not too happy about them.  I just finished changing over a number
> of functions, xlate amoung them, to always export the symbols, and
> then correctly return ENOTIMPL.
>
> Why the extra mad effort here?  It's an on/off switch.


The problem is that you can't teach the .dsp files to conditionally link 
with a library. The only way to simulate conditional linking is to 
provide a dummy library if the real one isn't available. And, since it's 
a dummy, it doesn't provide support for apr_xlate, so APR_HAS_XLATE 
doesn't get defined in this case.

(The changes I made to xlate.c were necessary because the symbols would 
_not_ get exported correclty in Windows #if APR_HAS_XLATE, that's all.)

>> However, if you drop the libiconv sources into i18n/win32/libiconv, 
>> build/win32iconv.bat will a) modify apr_config_iconv.h so that 
>> APR_HAS_XLATE, HAVE_ICONV_H and HAVE_ICONV are defined in the right 
>> places, and the _real_ iconv.lib/dll gets built and linked in.
>>
>> Yes, I know that smells of hackishness, but it's the best I could 
>> come up with on short notice without special tools (configure, etc) 
>> available. And we really need this support in Subversion ASAP, it has 
>> to go into our Alpha.
>
>
> Fine, then lets take the time to get this right.  I'm willing to help,
> I simply asked for breathing room till Wed.  Cool.  I had to get this
> support finished anyways.


Like I said, time is somethig we don't have if we want to get Subversion 
Alpha out the door by Thursday. I'm all for getting apr-iconv 
integrated, of course.

>>> Finally, it's libapriconv or libiconv.
>>
>>
>> Hm? I don't understand. What is libapriconv or libiconv?
>
>
> libiconv.dll - never iconv.dll please.  We are trying to stay somewhat
> in-sync with some unix conventions here so folks don't get as confused.


The build scripts that come with libiconv-1.8 create iconv.lib/dll, and 
I just copy that around. But it can obviously be renamed, no problem there.

>>> I'm reviewing the code now.  But I am confused.  Please enlighten
>>> me before you go checking this in... thanks,
>>
>>
>> Hope this is enlightening enough.
>
>
> Very, thanks.
>
> I'm 100% behind requiring win32 users to download apr-iconv as part
> of their apr build.  Be done with the custom tweakish build stuff 
> already,
> this is 2002.  We need xlate :-)


I dunno. You can use apr without apr-util; you should be able to use it 
without apr-iconv, too. And use apr-iconv without apr-util. And apr-util 
without apr-iconv (apr_md5 can work without iconv, after all).


-- 
Brane ─îibej   <brane@xbc.nu>   http://www.xbc.nu/brane/


Mime
View raw message