Mail Archives: djgpp-workers/2001/02/23/17:35:18
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
- Raw text -