Mail Archives: djgpp/2000/07/18/11:32:47
>but for the first version of the port I uploaded, I have inspected the
>following files:
> gettext.m4 (serial #5) from gettext-0.10.35
> gettext.m4 (serial #105) from grep-2.5a
> gettext.m4 (serial #107) from tar-1.13.17
> gettext.m4 (serial #109) from sh-utils-2.0i
>I have also inspected the ones from binutils-2.95 and gdb-4.18 (CYGNUS
>versions).
>[snip]
>I have never found **any ** kind of DJGPP support code in **anyone** of the
>above mentioned files.
>I have tested #5, #105 and #107 and everyone has found gettext in libc.a.
>Of course
>the wrong gettext. I have added DJGPP support to gettext.m4 (serial #107)
>and
>explained the way it worked at djgpp-workers. The port has been rejected
>due to
>the use of aclocal.
My mistake. I honestly believed that the fix was made by the gettext
maintainer, as I did not remember doing it myself. I guess it was me after
all. Here is the part that fixes things (and quite cleanly).
AC_CHECK_HEADER(libintl.h,
[AC_CACHE_CHECK([for gettext in libc], gt_cv_func_gettext_libc,
[AC_TRY_LINK([#include <libintl.h>],
[#if defined __DJGPP__
!barf! (DJGPP's gettext() isn't gettext!);
#else
return (int) gettext ("");
#endif],
gt_cv_func_gettext_libc=yes, gt_cv_func_gettext_libc=no)])
>IMHO, before trying to fix anything in one of the ports, a crucial question
>should be answered:
>1) Do we want to get NLS support out-of-the-box for every existing and
>future
> DJGPP port ?
>or
>2) Do we want to maintain compatibility with an old BORLAND compiler that
>is
> no longer produced nor maintained by BORLAND/IMPRISE ?
>
>If the first is wanted then conio.h has to be changed, IMHO.
>If the second is wanted then libintl.h must be changed. This means
>gettext must be renamed with the well known consequences for the
>configuration process.
I agree. This IS a problem. However, even for packages that DO compile
out-of-the-box, there is usually a specific DJGPP version available on
simtelnet as well. I do not feel it is excessive to ask of the people making
the DJGPP distributions to have perl, autoconf, and automake.
They can regenerate the configuration files and then prepare the package for
DJGPP distribution. The result will then configure and compile out-of-the
box for the end-user. And this without breaking programs that may rely on
the conio gettext function on MSDOS (I don't think any GNU package does, but
some autoconfed non-GNU packages might).
The main reason I didn't consider the configuration difficulties problems,
is that I ALWAYS regenerate the configuration files before configuring a GNU
package. For some reason, my system has always had difficulties using a
configure script without changes. Additionally, I'm not really fond of the
hacks introduced in the DJGPP port of bash to work around many configuration
problems; if feel the fixes should be made to the scripts, not the script
interpreter. IMHO, this would be the same as creating a new 'deleet'
operator to C++ because a certain group of users frequently mistypes
'delete'.
I've patched autoconf 2.14a with very little difficulties to work cleanly on
DOS, without (I think) relying on the bash hacks, or breaking the script on
non-DOS systems (although I have no means to test this). However, I am not
sure whether to release it as a DJGPP distribution. For one thing, it's a
beta package, and it also requires configure.in scripts to be rewritten
(there is a autoupdate script included that will do this for you, but it
will not always generate a correct script without user intervention, so
using it would require knowledge of the autoconf scripting system).
In any case, true out-of-the box NLS support would be impossible anyway; the
translation project almost always uses latin1 as charset for its PO files
(or the relevant charset for non-latin text). So the maintainer would have
to use recode to convert the PO file to, say, code pages 437 and 850 (they
seem the most widespread) before formatting them (and preferably update the
PO file header to reflect the charset change). If this does not happen,
non-ASCII characters (very often present in European translations such as
German or French) would not display correctly. in fact in order to make sure
international users can use the package out-of-the-box, the PO files would
need to be available in pretty much every IBM codepage (eg Poland uses 852,
I believe, and I'm sure there's plenty of other codepages in use). Not to
mention the special codepages/charsets that may be required by Asian
translations.
So, since, by your own admission, you need recode if using libintl,
NLS-enabled packages would no be usable out-of-the-box anyway, regardless of
how the gettext name-clash is handled...
Tim Van Holder
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
- Raw text -