From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.comp.lib.gnulib.bugs Subject: Re: Files from gnulib Date: Tue, 25 Jan 2011 06:24:56 -0500 Message-ID: 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1295954778 21311 80.91.229.12 (25 Jan 2011 11:26:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Jan 2011 11:26:18 +0000 (UTC) Cc: bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 25 12:26:10 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 1Phh2G-0003iD-NO for ged-emacs-devel@m.gmane.org; Tue, 25 Jan 2011 12:26:08 +0100 Original-Received: from localhost ([127.0.0.1]:40640 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phh2D-0003m0-Hn for ged-emacs-devel@m.gmane.org; Tue, 25 Jan 2011 06:26:05 -0500 Original-Received: from [140.186.70.92] (port=44393 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phh1p-0003gp-U9 for emacs-devel@gnu.org; Tue, 25 Jan 2011 06:25:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phh1c-000278-QG for emacs-devel@gnu.org; Tue, 25 Jan 2011 06:25:41 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:52736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phh1B-0001tL-6b; Tue, 25 Jan 2011 06:25:01 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1Phh16-0003H5-Qz; Tue, 25 Jan 2011 06:24:56 -0500 In-reply-to: <4D3E8E4C.1010000@cs.ucla.edu> (message from Paul Eggert on Tue, 25 Jan 2011 00:48:12 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:134928 gmane.comp.lib.gnulib.bugs:24905 Archived-At: > Date: Tue, 25 Jan 2011 00:48:12 -0800 > From: Paul Eggert > CC: monnier@iro.umontreal.ca, bug-gnulib@gnu.org, emacs-devel@gnu.org > > instead of doing the stuff I mentioned before the tarball is > created, we can add a shell script to be run after the tarball is > extracted. For example, on MS-DOS the c++defs.h file is > automatically renamed to cxxdefs.h by the extractor, so the script > can uniformly substitute "cxxdefs.h" for "c++defs.h" in all the text > files. Hopefully a similar idea works for all the other files with > non-MS-DOS names. The magic coded into the extractor utility is limited. It indeed handles file names with `+' in them, but does not handle arbitrary file names with multiple dots as a human would. It uses some convoluted algorithm to replace the extra dot with a `_' or a `-'; sometimes it replaces the first dot, sometimes the second. The results are often unpredictable or surprising, especially if, as it often happens, the modified names also clash in the 8+3 namespace (see below). So going this way means a much more complex and error-prone arrangement than a one-time rename of a small number of files. > I assume that the "configure" procedure for MS-DOS is already > different Yes, see config.bat in the top-level directory. But that's not the issue here. > > The files in m4/ still matter because you need to unpack the tarball, > > and the utility that does that won't silently overwrite files due to > > file-name clashes. > > That's OK. People can ignore those diagnostics The result is not ignorable diagnostics, but a prompt for the user to provide an alternate name. Since the user does not generally know whether these files are needed by the build, she will not be able to deal with the prompt. > just as I assume they already ignore the diagnostics for the files > whose names start with ".". No, there are no diagnostics for these conversions, they are done silently.