X-Originating-IP: [213.224.83.14] From: "Tim Van Holder" To: djgpp AT delorie DOT com Cc: ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De Subject: Re: ANNOUNCE: DJGPP port of GNU gettext-0.10.35 Date: Tue, 18 Jul 2000 12:09:34 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2000 12:09:34.0655 (UTC) FILETIME=[095BC4F0:01BFF0B1] Reply-To: djgpp AT delorie DOT com >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 ], [#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