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_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 17 05:42:53 2002