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 <[EMAIL PROTECTED]> http://www.xbc.nu/brane/