From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: Bruno Haible Date: Fri, 23 Feb 2001 23:34:33 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DJGPP specific patch for libiconv-1.5.1 CC: Eli Zaretskii , djgpp-workers AT delorie DOT com X-mailer: Pegasus Mail for Windows (v2.54DE) Message-ID: <2D6331E258B@HRZ1.hrz.tu-darmstadt.de> Reply-To: djgpp-workers AT delorie DOT com On Thu, 22 Feb 2001 23:56:22 +0100 (CET), Bruno Haible wrote: > > Due to the great amount of name collsions in this package, I would > > like to discuss the appropiate strategy for this package at > > djgpp-workers first. > > I like the fnchange.lst solution. It confines the problem to a single > file, and lets the Unix developers do their work without imposing > unduly 8+3 restrictions on them. On Fri, 23 Feb 2001 10:22:15 +0200, Eli Zaretskii wrote: > > I like the fnchange.lst solution. It confines the problem to a single > > file, and lets the Unix developers do their work without imposing > > unduly 8+3 restrictions on them. > > With all due respect, I'd suggest to reconsider this. [SNIP] Before talking about the ranaming or not renaming issue, it should be noticed that we are dealing with **two** different packages. In gettext, there are only difficulties with the filename tests/xgettext-[1-9] and tests/msgmerge-[1-5]. It can be seen that xgettext-[1-9] is mapped to xgettext and msgmerge-[1-5] is mapped to msgmerge-. This are the only name conflicts in the whole package. To resolve the conflict, Iwould suggest to rename the test scripts according to the following list: gettext-1 gettext.1 gettext-2 gettext.2 msgcmp-1 msgcmp.1 msgcmp-2 msgcmp.2 msgfmt-1 msgfmt.1 msgfmt-2 msgfmt.2 msgfmt-3 msgfmt.3 msgfmt-4 msgfmt.4 msgmerge-1 msgmerge.1 msgmerge-2 msgmerge.2 msgmerge-3 msgmerge.3 msgmerge-4 msgmerge.4 msgmerge-5 msgmerge.5 msgunfmt-1 msgunfmt.1 xgettext-1 xgettext.1 xgettext-2 xgettext.2 xgettext-3 xgettext.3 xgettext-4 xgettext.4 xgettext-5 xgettext.5 xgettext-6 xgettext.6 xgettext-7 xgettext.7 xgettext-8 xgettext.8 xgettext-9 xgettext.9 I know that the list contains all test scripts. This is intentional. IMHO, if *all* dashes are replaced by dots then the contents of the tests directory look more homogeneous than if only xgettext-[1-9] and msgmerge-[1-5] is renamed. Anyway, this is only a suggestion. Yesterday, I talk about libiconv and it looks bad. FYI, this is a list of all the filenames that do not conform to the DOS filename restriction. This means, they do not fit into the 8.3 namespace. The following files are not valid DOS file names: libiconv-1.5.1/include/iconv.h.in - too many dots libiconv-1.5.1/include/iconv.h.msvc-static - too many dots libiconv-1.5.1/include/iconv.h.msvc-shared - too many dots libiconv-1.5.1/tests/ARMSCII-8.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/tests/CP932.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/tests/CP950.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/tests/EUC-JP.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/tests/EUC-TW.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/tests/ISO-IR-165.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/tests/BIG5HKSCS.IRREVERSIBLE.TXT - too many dots libiconv-1.5.1/libcharset/tools/aix-3.2.5 - too many dots libiconv-1.5.1/libcharset/tools/aix-4.1.5 - too many dots libiconv-1.5.1/libcharset/tools/aix-4.2.0 - too many dots libiconv-1.5.1/libcharset/tools/aix-4.3.2 - too many dots libiconv-1.5.1/libcharset/tools/glibc-2.1.3 - too many dots libiconv-1.5.1/libcharset/tools/glibc-2.1.90 - too many dots libiconv-1.5.1/libcharset/tools/solaris-2.5.1 - too many dots libiconv-1.5.1/libcharset/tools/sunos-4.1.4 - too many dots libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-3.3.6 - too many dots libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-3.3.6 - too many dots libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-4.0.1f - too many dots libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-4.0.1f - too many dots libiconv-1.5.1/libcharset/include/libcharset.h.in - too many dots libiconv-1.5.1/libcharset/include/libcharset.h.msvc-shared - too many dots libiconv-1.5.1/libcharset/config.h.in - too many dots libiconv-1.5.1/libcharset/config.h.msvc - too many dots libiconv-1.5.1/lib/config.h.in - too many dots libiconv-1.5.1/lib/config.h.msvc - too many dots The following resolve to the same DOS file names: ALL-CHAR : libiconv-1.5.1/libcharset/tools/all-charsets libiconv-1.5.1/libcharset/tools/all-charsets-X11 CHECK-ST : libiconv-1.5.1/tests/check-stateful libiconv-1.5.1/tests/check-stateless CHECK-ST.BAT : libiconv-1.5.1/tests/check-stateful.bat libiconv-1.5.1/tests/check-stateless.bat CHECK-ST.CMD : libiconv-1.5.1/tests/check-stateful.cmd libiconv-1.5.1/tests/check-stateless.cmd CNS11643.H : libiconv-1.5.1/lib/cns11643.h libiconv-1.5.1/lib/cns11643_1.h libiconv-1.5.1/lib/cns11643_2.h libiconv-1.5.1/lib/cns11643_3.h libiconv-1.5.1/lib/cns11643_inv.h ENCODING.DEF : libiconv-1.5.1/lib/encodings.def libiconv-1.5.1/lib/encodings_aix.def libiconv-1.5.1/lib/encodings_local.def GENALIAS.C : libiconv-1.5.1/lib/genaliases.c libiconv-1.5.1/lib/genaliases2.c GEORGIAN.H : libiconv-1.5.1/lib/georgian_academy.h libiconv-1.5.1/lib/georgian_ps.h GEORGIAN.TXT : libiconv-1.5.1/tests/Georgian-Academy.TXT libiconv-1.5.1/tests/Georgian-PS.TXT GLIBC-2.2-X : libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-3.3.6 libiconv-1.5.1/libcharset/tools/glibc-2.2-XF86-4.0.1f ICONV.HMS : libiconv-1.5.1/include/iconv.h.msvc-shared libiconv-1.5.1/include/iconv.h.msvc-static ISO-2022 : libiconv-1.5.1/tests/ISO-2022-CN-EXT-snippet libiconv-1.5.1/tests/ISO-2022-CN-snippet libiconv-1.5.1/tests/ISO-2022-JP-1-snippet libiconv-1.5.1/tests/ISO-2022-JP-2-snippet libiconv-1.5.1/tests/ISO-2022-JP-snippet libiconv-1.5.1/tests/ISO-2022-KR-snippet ISO-2022.UTF : libiconv-1.5.1/tests/ISO-2022-CN-EXT-snippet.UTF-8 libiconv-1.5.1/tests/ISO-2022-CN-snippet.UTF-8 libiconv-1.5.1/tests/ISO-2022-JP-1-snippet.UTF-8 libiconv-1.5.1/tests/ISO-2022-JP-2-snippet.UTF-8 libiconv-1.5.1/tests/ISO-2022-JP-snippet.UTF-8 libiconv-1.5.1/tests/ISO-2022-KR-snippet.UTF-8 ISO-8859.TXT : libiconv-1.5.1/tests/ISO-8859-1.TXT libiconv-1.5.1/tests/ISO-8859-10.TXT libiconv-1.5.1/tests/ISO-8859-13.TXT libiconv-1.5.1/tests/ISO-8859-14.TXT libiconv-1.5.1/tests/ISO-8859-15.TXT libiconv-1.5.1/tests/ISO-8859-16.TXT libiconv-1.5.1/tests/ISO-8859-2.TXT libiconv-1.5.1/tests/ISO-8859-3.TXT libiconv-1.5.1/tests/ISO-8859-4.TXT libiconv-1.5.1/tests/ISO-8859-5.TXT libiconv-1.5.1/tests/ISO-8859-6.TXT libiconv-1.5.1/tests/ISO-8859-7.TXT libiconv-1.5.1/tests/ISO-8859-8.TXT libiconv-1.5.1/tests/ISO-8859-9.TXT ISO2022_.H : libiconv-1.5.1/lib/iso2022_cn.h libiconv-1.5.1/lib/iso2022_cnext.h libiconv-1.5.1/lib/iso2022_jp.h libiconv-1.5.1/lib/iso2022_jp1.h libiconv-1.5.1/lib/iso2022_jp2.h libiconv-1.5.1/lib/iso2022_kr.h ISO8859_.H : libiconv-1.5.1/lib/iso8859_1.h libiconv-1.5.1/lib/iso8859_10.h libiconv-1.5.1/lib/iso8859_13.h libiconv-1.5.1/lib/iso8859_14.h libiconv-1.5.1/lib/iso8859_15.h libiconv-1.5.1/lib/iso8859_16.h libiconv-1.5.1/lib/iso8859_2.h libiconv-1.5.1/lib/iso8859_3.h libiconv-1.5.1/lib/iso8859_4.h libiconv-1.5.1/lib/iso8859_5.h libiconv-1.5.1/lib/iso8859_6.h libiconv-1.5.1/lib/iso8859_7.h libiconv-1.5.1/lib/iso8859_8.h libiconv-1.5.1/lib/iso8859_9.h ISOIR165.H : libiconv-1.5.1/lib/isoir165.h libiconv-1.5.1/lib/isoir165ext.h LOCALE_C.C : libiconv-1.5.1/libcharset/tools/locale_charset.c libiconv-1.5.1/libcharset/tools/locale_codeset.c MACROMAN.TXT : libiconv-1.5.1/tests/MacRoman.TXT libiconv-1.5.1/tests/MacRomania.TXT MAC_ROMA.H : libiconv-1.5.1/lib/mac_roman.h libiconv-1.5.1/lib/mac_romania.h There are two approaches IMHO: a) Doing nothing. Nothing is changed, the package remains as it is. Then the package can be configured and compiled *more or less* out-of-the-box on win9x. This means LFN support *must* be available for configuring, compiling, testing and installing and users of msdos/freedos/opendos (only SFN support) will be excluded. Of course, a DJGPP port always consist of three zip files: binaries, docs and sources, so the DJGPP users will be able to use the port on plain DOS but they will not be able to change the sources and recompile the package. b) A DJGPP specific solution. A djgpp directory must be created in libiconv-1.5.1. This directory will contain all the files needed to "patch" the sources on-the-fly while configuring. There will be three kind of files: fnchange.lst, config.bat and some sed scripts. The user that wants to compile libiconv-1.x.x.tar.gz out-of-the-box will have to use DJGPP's djtar program together with the provided fnchange.lst. djtar allows file renaming on-the-fly. This list (fnchange.lst) will contain all filenames that must be changed (old filename new filename). After having unzipped the archive, the package must be configured for MSDOS/DJGPP. This will be done by running config.bat. This batch file will change all files that need to be changed using a serie of supplied sed scripts. Once again: the filename conflicts will be resolved by unzipping the archive in a DJGPP specific way and by modifing the sources accordingly. Of course, all this will *not* interfere with the way libiconv configures and compiles for other targets. And for a DJGPP user all this will happen behind the sceens. To resolve the name conflict, new directories are created while unzipping. Filenames like iso8895_XX.h resolve to the same filename iso8895_.h on plain DOS. This can be avoided by extracting this files into a new directory. Example: lib/iso8859_XX.h become lib/ISO/8859_XX.h lib/iso2022_XXXX.h become lib/ISO/2022_XXXX.h lib/isoir165XXX.h become lib/ISO/ir165XXX.h All ISO files can be moved into a new ISO directory. The same applies to the cns11643XX.h, mac_XXXXXX.h, encondings_XXX.def and other files more: lib/cns11643_XXX.h become lib/CNS/11643_XXX.h lib/mac_XXXXXXXX.h become lib/MAC/XXXXXXXXX.h Once again: there are much more files that need to be treated. The above are only examples of what must be done. Of course, the sources and Makefiles must be modified to reflect this new directory structure accordingly. The same applies to the test directory. I have no preferences. I have patches for both solutions. Of course, if someone knows a better solution, please let me know and I will make a new patch. On Fri, 23 Feb 2001 10:11:02 +0200, Eli Zaretskii wrote: > (usage) [O_BINARY]: Print --binary option. > > I probably missed this when I read your previous set of patches. > > Why is the --binary option needed? Why cannot the files be always > read and written in binary mode? I would agree. The default operation mode of iconv.exe should be with O_BINARY on WinDos. It is worth to be noticed that the testsuit of libiconv does *not* work properly on WinDos due to the default O_TEXT mode reading and writting. I solved the difficulty by adding the following snippet to check-stateful [SNIP] # For systems that distinguish between text and binary I/O # the binary mode of iconv must be selected and for # systems with severe filename restrictions allow for # an alternate filename. UNAME=${UNAME-`uname 2>/dev/null`} case X$UNAME in *-DOS) MODE='--binary' filename=`echo "$charset" | sed "s|ISO-|ISO/|;s|2022-|2022|"` ;; *) MODE='' filename="$charset" ;; esac ../src/iconv $MODE -f "$charset" -t UTF-8 < "${srcdir}"/"$filename"-snippet > tmp-snippet [SNIP] Anyway, this must be decided by Bruno. Regards, Guerrero, Juan Manuel