X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
In-Reply-To:	<200702250505.l1P551lH010566@delorie.com>
Subject:	Re: ANNOUNCE: DJGPP port of Expat 2.0.0 uploaded
To:	djgpp AT delorie DOT com
X-Mailer:	Lotus Notes Release 7.0.2 September 26, 2006
Message-ID:	<OF1BC815CD.26E02197-ON8725728E.0057EC47-8725728E.005A1C23@seagate.com>
From:	Gordon DOT Schumacher AT seagate DOT com
Date:	Mon, 26 Feb 2007 09:24:16 -0700
X-MIMETrack:	Serialize by Router on SV-GW1/Seagate Internet(Release 7.0.1 HF29|March 07, 2006) at
	02/26/2007 08:24:20 AM
MIME-Version:	1.0
X-Proofpoint-FWRule:	outbound2
X-Proofpoint-Virus-Version:	vendor=fsecure engine=4.65.5502:2.3.11,1.2.37,4.0.164 definitions=2007-02-26_05:2007-02-24,2007-02-26,2007-02-26 signatures=0
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id l1QGOaMV007548
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de> wrote on Sat, 24 Feb 2007
21:08:03 +0100:

# First, thank you for your ports.  Neitherless I would like to make some
minor
# comments:
#   1)  It would be nice to have formated man pages instead of the raw
ones.
#       This formated ones must usualy be produced manualy by the porter of
#       the package because the GNU Makefile does not care about this
issue.
#       All this implies that the porter deletes the /man/man1 (or what
ever
#       it is called) and repleces it with a /man/cat1 (or what ever it is
#       called). In this new dir the formated man pages will be stored.

Hm, that hadn't occurred to me; that's with groff, yes?

# [snip]
#
#       If the user starts the command rm -vfr @manifest\expat20b.mft, not
only
#       the intended binary bin/xmlwf.exe will be deleted, but also the
complete
#       /bin directory with all its containts.  This is certainly not
intended
#       neither by the porter of the package nor by the user.

Ack, indeed.  I will modify my find command to reflect that.

#       On an SFN system the name /expat-2.0.0 will not be unique.  One
unzip
#       program may translate this as /expat-2.0-0 another one may convert
this
#       to /expat-2.00 or something else.  This will have nasty
consequences if
#       it is the name of a header or a library.  It is responsability of
the
#       porter to choose appropriate file names that conform the 8.3 file
name
#       restriction.

I can do that for the parent src directory to ensure that it doesn't
conflict
with any other directory that the user has in their DJGPP/src already, but
what
I did for testing was to ensure that the filenames remained unique by using
the
DJGPP-"blessed" unzip32 tool which simply truncates names.  That is what is
required for them to still build properly under DJGPP without
modification...

That seemed easier than converting all the filenames to 8.3 format, while
still
ensuring that the package could build on both an LFN and a SFN system.

Also, I have to ask how critical "real" SFN support is, with the existence
of
the DOSLFN package?  That adds LFN support to a pure DOS system.

- Raw text -