From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: Proposed gnulib renames Date: Wed, 26 Jan 2011 16:39:43 -0800 Organization: UCLA Computer Science Department Message-ID: <4D40BECF.7090602@cs.ucla.edu> References: <4D404396.9040600@redhat.com> <87tygvmxk5.fsf@meyering.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1296088804 25374 80.91.229.12 (27 Jan 2011 00:40:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Jan 2011 00:40:04 +0000 (UTC) Cc: bug-gnulib , Bruno Haible , cyd@stupidchicken.com, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, Eli Zaretskii , Eric Blake To: Jim Meyering Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Thu Jan 27 01:39:59 2011 Return-path: Envelope-to: gnu-bug-gnulib@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 1PiFu2-0005UA-U5 for gnu-bug-gnulib@m.gmane.org; Thu, 27 Jan 2011 01:39:59 +0100 Original-Received: from localhost ([127.0.0.1]:57776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiFu2-000408-2G for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 19:39:58 -0500 Original-Received: from [140.186.70.92] (port=42139 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiFts-0003y5-VA for bug-gnulib@gnu.org; Wed, 26 Jan 2011 19:39:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiFtr-0001lG-Kk for bug-gnulib@gnu.org; Wed, 26 Jan 2011 19:39:48 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:59543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiFtr-0001l6-9H; Wed, 26 Jan 2011 19:39:47 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2F97439E80DF; Wed, 26 Jan 2011 16:39:45 -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 qx6RQqrmluRf; Wed, 26 Jan 2011 16:39:44 -0800 (PST) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4217539E80DB; Wed, 26 Jan 2011 16:39:44 -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: <87tygvmxk5.fsf@meyering.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:25006 gmane.emacs.devel:135057 Archived-At: On 01/26/11 08:36, Jim Meyering wrote: > Renaming files like those to avoid the 8.3 collisions does not seem > like the right move, especially since we (at least I) have no idea of > the size of the user base we would be accommodating. I agree that wholesale renaming is not a realistic option. It appears that Eli has a solution for c++defs and there's no need to worry about it right now. The *.in.h problem is more serious, though, as it limits include file names to 7 letters before the dot. For example, in DOS, the name "fnmatch-in.h" is equivalent to "fnmatch.h" (the excess chars "-in" are ignored by the file system), so one cannot have a Make rule that creates the latter from the former. Currently this is not a problem since all the .in.h files that Emacs uses are 7 characters or less. But this is not a tenable restriction in the long run. One thing does strike me, though, as being a useful thing we can do regardless of the DOS business. Currently we build lib/c++defs.h from build-aux/c++defs.h as part of ordinary 'make'. But lib/c++defs.h is the same on all platforms. It would save work for ordinary 'make' if we distributed lib/c++defs.h, so that the maintainer can build it rather than the builder. Similarly for lib/warn-on-use.h and lib/arg-nonnull.h. I can propose gnulib changes along those lines, unless there's some objection. I don't expect this to affect the difficulty of the Emacs MS-DOS build.