From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Compartmentalizing the 8.3 problem into the msdos directory Date: Sat, 05 Feb 2011 03:20:30 -0800 Organization: UCLA Computer Science Department Message-ID: <4D4D327E.9010806@cs.ucla.edu> References: <83y66bzuhc.fsf@gnu.org> <4D3C81A1.70009@cs.ucla.edu> <83ipxfymox.fsf@gnu.org> <4D3E0A8E.1030400@cs.ucla.edu> <8362tdzl7m.fsf@gnu.org> <4D3E8E4C.1010000@cs.ucla.edu> <4D3F1171.5010201@cs.ucla.edu> <83y668yfgt.fsf@gnu.org> <4D3F3F7B.40402@cs.ucla.edu> <83ipxcy6xw.fsf@gnu.org> <4D3F70B8.3090708@cs.ucla.edu> <83d3nkxq31.fsf@gnu.org> <4D412D83.1010503@cs.ucla.edu> <4D427084.3010502@cs.ucla.edu> <837hdphzyr.fsf@gnu.org> <4D4680EE.2020404@cs.ucla.edu> <83d3n6agrk.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1296904852 28424 80.91.229.12 (5 Feb 2011 11:20:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 5 Feb 2011 11:20:52 +0000 (UTC) Cc: cyd@stupidchicken.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 05 12:20:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PlgC3-00027X-PG for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2011 12:20:43 +0100 Original-Received: from localhost ([127.0.0.1]:58076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PlgC3-00028m-7a for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2011 06:20:43 -0500 Original-Received: from [140.186.70.92] (port=44807 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PlgBy-00028h-61 for emacs-devel@gnu.org; Sat, 05 Feb 2011 06:20:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PlgBx-0005NS-4G for emacs-devel@gnu.org; Sat, 05 Feb 2011 06:20:38 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:37255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PlgBv-0005NC-KX; Sat, 05 Feb 2011 06:20:35 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 99AB839E80DF; Sat, 5 Feb 2011 03:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL2XwOQw7yCv; Sat, 5 Feb 2011 03:20:31 -0800 (PST) Original-Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id EF2D139E80DB; Sat, 5 Feb 2011 03:20:30 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 In-Reply-To: <83d3n6agrk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:135609 Archived-At: On 02/05/2011 02:59 AM, Eli Zaretskii wrote: > . It will effectively block a release, until msdos/fnchange.prs is > fixed. We can easily give an option to override that, if necessary. But the idea is that such an option should not be needed, because the normal state of affairs is that fnchange.prs should be sufficiently up-to-date. Even if (due to some last-second screwup) it's not up-to-date, fnchange.prs is easy enough for the releaser to fix without knowing all the ins and outs of MS-DOS 8+3 rules. > . It needs to run on plain DOS, and so can only use features > supported by the extremely primitive command.com shell available > there. For example, it cannot even recurse through arbitrary > directory trees. That can be handled in the same way that the file-renaming is handled: do the 'find' on Linux as part of the release process, distribute the output of 'find' as a file, and have the DOS build procedure read that file. This essentially removes the potential for error that you mentioned. > . Editing files generally changes their time stamps, which could > then trigger Make rules not intended to run at end-user build > time If the DOS procedure edits files in the proper order, the resulting time stamps should be consistent with what 'make' expects. The remaining problems you mentioned seem to be largely theoretical. They might occur if we start to use unusually tricky file names, but these problems don't exist now and are unlikely to occur. If they do happen, we can deal with those problems by hand, as they come up. Ordinarily long file names shouldn't trigger any of those problems.