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