Ok perfect. But in fact I may have found solution where it may be not at all needed finally and still understand all the encodings possible (in fact in a terminal, there are not so many encoding conversions to be done. We don't necessarily need a tool as complete as iconv). But I am still not sure to deal with all possible cases. And for the few conversions which are required, there may be some X functions able to deal with it.
But anyway I keep your authorization in mind. If I can avoid to use iconv in any case, I will. If not, I will just make it a permanent requirement. I will keep you up to date, and keep reading the source code and browsing the web. ;-) Jehan Terminator writes: > iconv is already a mandatory requirement for xft. so I think to make it a > permanent requirement shouldn't be a problem. thanks for the efforts. :-) > > > On Fri, Jul 25, 2008 at 8:24 AM, jehan <[EMAIL PROTECTED]> wrote: > >> Apparently here is how this dependency is defined currently (configure.ac: >> 1016): >> >> if test "x$support_xft x$support_cjk" = "xyes xyes"; then >> dnl BSD and Cygwin needs libiconv >> AC_CHECK_LIB(iconv, iconv_open) >> dnl hack for Mac OS X >> if test "x$local_os_type" = "xdarwin"; then >> LIBS="$LIBS -liconv" >> fi >> dnl hack for Cygwin >> if test "x$local_os_type" = "xcygwin"; then >> LIBS="$LIBS -liconv" >> fi >> dnl hack for Cygwin >> if test "x$local_os_type" = "xopenbsd"; then >> LIBS="$LIBS -liconv" >> fi >> fi >> >> So what I understand here is that this is mandatory when you have Darwin, >> Cygwin or OpenBSD and not used at all in any other case, is this it? >> >> But then what is the following part of the configure.ac:1070 : >> >> AC_CHECK_HEADERS( \ >> arpa/inet.h \ >> assert.h \ >> fcntl.h \ >> iconv.h \ >> [...] >> ) >> >> ??? Shouldn't the AC_CHECK_HEADER be inside the "if" (darwin, or cygwin or >> openbsd)? Here it would check for existence of this header in any case, no? >> So this is already a mandatory lib? >> >> I am not sure to understand everything because I am not an expert of >> autoconf/automake (I only used these tools once for a small project >> something like 2 years ago, so I don't remember well all this...). >> See you! >> >> Jehan >> >> jehan writes: >> >> > Hello all, >> > >> > about libiconv, could we consider to use it as a mandatory dependency? >> Here >> > are several reasons why it would be a good thing: >> > >> > 1/ I think it can be found anyway on most Linux and Unix machines. As far >> as >> > I know, it is part of POSIX (so all we should do is to take care of not >> use >> > options from specific implementations, if any, as the GNU one, but the >> > generic standard functions only)... >> > >> > 2/ With the new design of mrxvt I have in mind, this would enable to have >> a >> > single generic logic, whatever locale you may use, as long as it is >> > supported by their iconv implementation. >> > If you have a look to the GNU implementation for instance, it has a >> fairly >> > broad number of encodings: http://www.gnu.org/software/libiconv/ >> > And mrxvt would just support all this as well! >> > >> > 3/ As a last resort, I could use again a compiler #ifdef check depending >> or >> > not whether the configure found a libiconv on the computer. This way it >> > could still compile without this. But I don't think this is a good >> solution >> > as it let think that it may work also without iconv. But the reality is >> that >> > currently our implementation is broken for most "common" encodings. Just >> > have a look at encoding.c, and you will see that most encodings are >> > processed the same way (rxvt_decode_dummy), which means "badly" decoded, >> > simply (even the ISO-8859-X encodings, typical for most european >> languages, >> > are in fact badly supported for the most part). >> > >> > Using obligatory libiconv will just fix all this in one single shot. >> Keeping >> > separate alternatives will need people to try to make a decoding function >> > for every encoding, which may never happen, and is at the end only >> > "rewriting" libiconv after all... so what is the interest? >> > >> > So what is your opinion? >> > >> > Jehan >> > >> > ------------------------------------------------------------------------- >> > This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> > Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> > Grand prize is a trip for two to an Open Source event anywhere in the >> world >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> > _______________________________________________ >> > Materm-devel mailing list >> > Materm-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/materm-devel >> > mrxvt home page: http://materm.sourceforge.net >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Materm-devel mailing list >> Materm-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/materm-devel >> mrxvt home page: http://materm.sourceforge.net >> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Materm-devel mailing list Materm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/materm-devel mrxvt home page: http://materm.sourceforge.net
