Date: Sat, 24 Feb 2001 10:29:22 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De
Message-Id: <2593-Sat24Feb2001102921+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: haible AT ilog DOT fr, djgpp-workers AT delorie DOT com
In-reply-to: <2D6331E258B@HRZ1.hrz.tu-darmstadt.de>
	(ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De)
Subject: Re: DJGPP specific patch for libiconv-1.5.1
References:  <2D6331E258B AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
> Organization: Darmstadt University of Technology
> Date: Fri, 23 Feb 2001 23:34:33 +0200
> 
> 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.

When you consider this option, please remember that Microsoft is
actively working to leave less and less platforms where you can safely
build and run DJGPP programs and have long file names.  Windows 2000
is already unsuitable for any serious DJGPP development, and
Windows/ME surely looks like the second worst choice after W2K (see a
few reports on comp.os.msdos.djgpp).  So it is quite possible that
packages which require LFN to build will soon enough be impossible to
build natively except by a lucky few.

>    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

Why cannot the official package be restructured so that it already has
all those directories?