[Materm-devel] libiconv (fwd)

[jehan <je...@ze...>]

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/materm-devel
> mrxvt home page: http://materm.sourceforge.net