From: Bruno H. <ha...@il...> - 2002-04-22 11:43:26
|
Hi Sam, I have moved the libiconv directory out of clisp cvs. It is now at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libiconv/ This being done the way is free for you to remove it from the clisp cvs: cd clisp files=`find libiconv -type f | grep -v /CVS/` rm -f $files cvs remove $files cvs commit $files and update the surrounding infrastructure to use iconv() if available and only if found in glibc or GNU libiconv. (Other iconv implementations are unreliable.) The points needing care are: - top level configure - makemake.in - definition of GNU_LIBICONV in lispbibl.d. Bruno |
From: Sam S. <sd...@gn...> - 2002-04-22 19:09:27
|
Dear Bruno, > * In message <155...@ho...> > * On the subject of "libiconv cvs has moved" > * Sent on Mon, 22 Apr 2002 13:41:41 +0200 (CEST) > * Honorable Bruno Haible <ha...@il...> writes: > > I have moved the libiconv directory out of clisp cvs. It is now at > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libiconv/ okay. > and update the surrounding infrastructure to use iconv() if available > and only if found in glibc or GNU libiconv. do I understand correctly that the CLISP cannot do UNICODE without a usable iconv? on freebsd, `man -k iconv` returns nothing; does it mean that we lose UNICODE on that platform right away? > (Other iconv implementations are unreliable.) why not let the autoconf decide on this? how can one check whether iconv() understands UNICODE? > The points needing care are: > - top level configure > - makemake.in > - definition of GNU_LIBICONV in lispbibl.d. Actually, I thought you were going to do it. :-( -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> <http://www.palestine-central.com/> <http://www.mideasttruth.com/> The only thing worse than X Windows: (X Windows) - X |
From: Bruno H. <ha...@il...> - 2002-04-23 11:50:32
|
Sam writes: > do I understand correctly that the CLISP cannot do UNICODE without a > usable iconv? Wrong. UNICODE will work on these platforms as well - because I have hardcoded the most important encodings in encoding.d. The only thing that will be different is that the number of available encodings will be smaller (see encoding.d:encoding_from_name()). > > (Other iconv implementations are unreliable.) > why not let the autoconf decide on this? An autoconf test doing that would take 1 minute of configure time and use several megabytes of data. It's better to just hardcode the known good iconv()s. > how can one check whether iconv() understands UNICODE? $ echo | iconv -f ASCII -t UNICODE We already have a good determination of CLISP_INTERNAL_CHARSET in stream.d. Bruno |
From: Sam S. <sd...@gn...> - 2002-04-23 14:07:55
|
> * In message <155...@ho...> > * On the subject of "Re: libiconv cvs has moved" > * Sent on Tue, 23 Apr 2002 13:48:35 +0200 (CEST) > * Honorable Bruno Haible <ha...@il...> writes: > > Sam writes: > > > > (Other iconv implementations are unreliable.) > > why not let the autoconf decide on this? > > An autoconf test doing that would take 1 minute of configure time and > use several megabytes of data. It's better to just hardcode the known > good iconv()s. in the original email you said that the only good iconv() is the one in glibc2.2; in impnotes you list other good iconv()s. why not use it whenever it is available since, as you said, the most important encodings are already hardcoded? if a user installs libiconv under /usr/local/ on, say, solaris (which has /usr/include/iconv.h), how can we make sure we include the right iconv.h? What you are proposing is, essentially, making HAVE_ICONV == GNU_LIBICONV right? another thing, libcharset is in libiconv but not in glibc. do I need to integrate locale_charset() in encoding.d? -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> <http://www.palestine-central.com/> <http://www.mideasttruth.com/> Murphy's Law was probably named after the wrong guy. |
From: Bruno H. <ha...@il...> - 2002-05-13 11:22:32
|
Sam wrote in April: > in the original email you said that the only good iconv() is the one in > glibc2.2; in impnotes you list other good iconv()s. In impnotes I list other iconv()s; I wrote libiconv precisely because I found that they were not good enough. Maybe it has changed a bit over the last three years, but not a lot. > why not use it whenever it is available since, as you said, the most > important encodings are already hardcoded? Reliability. You don't want people to send you clisp crash reports about this. > if a user installs libiconv under /usr/local/ on, say, solaris (which > has /usr/include/iconv.h), how can we make sure we include the right > iconv.h? --prefix=/usr/local or, if --prefix is already different, --with-libiconv-prefix=/usr/local. Bruno |