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.
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?
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.
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.
>>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.
>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.
>>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.
>>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 :-)
Bill
---------------------------------------------------------------------
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:08:41 2002