You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2002/07/23 01:41:05 UTC
Alpha on Win32 without UTF8 conversion
FYI,
As far as I'm concerned, Subversion Alpha on Win32 won't do encoding
conversions. APR-iconv can't work even theoretically, because none of
the conversion modules are compiled. Even if they were, I don't see how
apr-iconv could work with the table-based encodings -- they never seem
to get loaded -- and support for charset aliases is practially nonexistent.
I tried very hard to put support for using the GNU libiconv into APR,
but the only result was comments to about how ASF doesn't like GPL code,
and that the apr_xlate code got moved around, making my patch worthless.
Anyway. I've had enough of this, and am not going to touch that code
again for some time. My patches are all in the mailing archives, so if
somebody wants to take this up on the APR list and/or work on them,
you're welcome. I have neither time nor energy any more to track and
argue about certain hacks that have been going into the APR code.
--
Brane Čibej <br...@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
Re: Alpha on Win32 without UTF8 conversion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
cmpilato@collab.net writes:
> Once I made that change locally, it opened up a whole new can of worms
> such that I was unable to build at all (other symbols undefined and so
> on). I was already a couple of stack frames deep at that point, so I
> aborted and moved on. Was planning on checking this out here at home
> tonight.
:-(
Which jives with what Brane was saying about it all being horked.
Okay, thanks for the report...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha on Win32 without UTF8 conversion
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Branko Äibej <br...@xbc.nu> writes:
> > O.K., here's a summary:
> >
> > [...]
>
> Thanks for taking time to list these, Brane!
>
> One question, more directed at Mike than Brane: the reason we were
> failing to get conversion working on Win32 so far was just that mess
> with the preprocessor symbol (APU_HAS_ vs APU_HAVE_). Did you ever
> get a chance to test with that symbol fixed, so that the relevant code
> was entered, and if so did it convert as advertised?
Once I made that change locally, it opened up a whole new can of worms
such that I was unable to build at all (other symbols undefined and so
on). I was already a couple of stack frames deep at that point, so I
aborted and moved on. Was planning on checking this out here at home
tonight.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha on Win32 without UTF8 conversion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> O.K., here's a summary:
>
> [...]
Thanks for taking time to list these, Brane!
One question, more directed at Mike than Brane: the reason we were
failing to get conversion working on Win32 so far was just that mess
with the preprocessor symbol (APU_HAS_ vs APU_HAVE_). Did you ever
get a chance to test with that symbol fixed, so that the relevant code
was entered, and if so did it convert as advertised?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha on Win32 without UTF8 conversion
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>Brane, if you can (pleeeeease) take the time to summarize briefly the
>problems you know of, and a checklist of whether or not you've got
>solutions for those problems (perhaps pending in mailing list
>archives), I'd be glad to take a stab at picking up where you left
>off.
>
>
O.K., here's a summary:
* Paths in APR:
o We must have a way to find out what encoding the file names
produced and consumed by APR have, because on WinNT, those
will always be in UTF-8, regardless of the current locale
settings. See my message and resulting thread in dev@apr:
Subject: [PATCH] Determining the character encoding used for paths in APR
* Determining the default locale encoding:
o apr_xlate.h defines APR_LOCALE_CHARSET, which you can pass
to apr_xlate_open to have it figure out the encoding used by
the current locale. The implementation is unix-only. I wrote
a patch for Windows; I'm attaching the relevant bits of that
patch.
o Now that apr_xlate is in apr-util, that patch has to be
broken out and the code moved into APR. I suggested two new
functions, apr_os_locale_encoding and
apr_os_default_encoding, that would replace the
get_locale_charset and get_default_charset in xlate.c.
* Getting a working iconv library
o apr-iconv isn't.
o I still think supporting GNU libiconv is the way to go. See
my mail in dev@subversion:
Subject: Re: Is --enable-utf8 working everywhere?
Message-ID: <3D...@xbc.nu>
Either the solition that detects and builds the libiconv
sources, or one that detects and links with a pre-compiled
libiconv, would be fine. Note that we wouldn't distribute
any LGPL code, nor make libiconv binaries available -- just
tell users how to build them. For the win32 binaries on the
sownload site, it'd be quite enought to add a link to the
gnu site where the sources are available; it's not as if
we're changing that source.
Please ask if any of this isn't clear.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Alpha on Win32 without UTF8 conversion
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> FYI,
>
> As far as I'm concerned, Subversion Alpha on Win32 won't do encoding
> conversions. APR-iconv can't work even theoretically, because none of
> the conversion modules are compiled. Even if they were, I don't see how
> apr-iconv could work with the table-based encodings -- they never seem
> to get loaded -- and support for charset aliases is practially nonexistent.
>
> I tried very hard to put support for using the GNU libiconv into APR,
> but the only result was comments to about how ASF doesn't like GPL code,
> and that the apr_xlate code got moved around, making my patch worthless.
>
> Anyway. I've had enough of this, and am not going to touch that code
> again for some time. My patches are all in the mailing archives, so if
> somebody wants to take this up on the APR list and/or work on them,
> you're welcome. I have neither time nor energy any more to track and
> argue about certain hacks that have been going into the APR code.
Brane, if you can (pleeeeease) take the time to summarize briefly the
problems you know of, and a checklist of whether or not you've got
solutions for those problems (perhaps pending in mailing list
archives), I'd be glad to take a stab at picking up where you left
off.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org