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 15:30:54 -0800 Organization: UCLA Computer Science Department Message-ID: <4D4DDDAE.3060401@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> <4D4D327E.9010806@cs.ucla.edu> <83aaiaafiw.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 1296948676 27018 80.91.229.12 (5 Feb 2011 23:31:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 5 Feb 2011 23:31:16 +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 Sun Feb 06 00:31:11 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 1Plrav-0007lA-VF for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2011 00:31:10 +0100 Original-Received: from localhost ([127.0.0.1]:40590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Plrau-0000BM-R5 for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2011 18:31:08 -0500 Original-Received: from [140.186.70.92] (port=56213 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Plraq-0000BC-Fw for emacs-devel@gnu.org; Sat, 05 Feb 2011 18:31:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Plrap-0002jh-Iy for emacs-devel@gnu.org; Sat, 05 Feb 2011 18:31:04 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:60620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Plrao-0002if-3m; Sat, 05 Feb 2011 18:31:02 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 0C05139E80F0; Sat, 5 Feb 2011 15:31:00 -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 5PQSziAJCgq2; Sat, 5 Feb 2011 15:30:59 -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 730CD39E80DB; Sat, 5 Feb 2011 15:30:59 -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: <83aaiaafiw.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:135625 Archived-At: On 02/05/2011 03:26 AM, Eli Zaretskii wrote: >> If they do happen, we can deal with those problems by hand, as they >> come up. > > We do that now, and see where it got us. Yes, right now "make dist" in the Emacs trunk doesn't obey the 8+3 restrictions. My proposal would fix all six violations, automatically. I'm trying to make it easier for mainstream developers to be largely unaffected by DOS filename limits. With a bit of luck this method will work for all the file names developers are likely to add later. But even if there are a few exceptions that require fixing by hand, we'll still be much better off than we are now. >> The remaining problems you mentioned seem to be largely theoretical. > > Not if limitations on file names are lifted entirely. I'm not proposing lifting *all* naming limitations. Just lifting them enough so that as a practical matter, non-DOS developers can almost always stop worrying about this stuff. >> We can easily give an option to override that, if necessary. > > Then it _will_ be used, and the whole point is moot. It's not moot. It will be up to the person making the release to decide whether a last-second 8+3 problem needs to be fixed before the release is actually cut. Releasers already have to make these sorts of decisions; the change would help them do their job better, by automating the checks. >> 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. > > More complications for the release process. It's a small script, easily written, and reliable once written. >> If the DOS procedure edits files in the proper order, the resulting >> time stamps should be consistent with what 'make' expects. > > I very much doubt that there exists a "proper order" I don't see why not. Any order that satisfies Make's dependencies will do. Just generate the files in the same order that 'make' does. I see no significant technical impediment to the proposal. If the MS-DOS port is important enough to keep, then it's important enough to improve its release process in this way, so that its 8+3 limits don't continue to impede mainstream development.