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: 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 Content-type: text/plain; charset=ISO-8859-1 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 Content-Transfer-Encoding: 8bit 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 Precedence: bulk Juan Manuel Guerrero 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.