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: Files from gnulib Date: Tue, 25 Jan 2011 16:54:16 -0800 Organization: UCLA Computer Science Department Message-ID: <4D3F70B8.3090708@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> 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 1296003276 28279 80.91.229.12 (26 Jan 2011 00:54:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 26 Jan 2011 00:54:36 +0000 (UTC) Cc: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Wed Jan 26 01:54:31 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 1PhteY-0001vD-Rt for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 01:54:31 +0100 Original-Received: from localhost ([127.0.0.1]:40755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhteX-0005Qi-RU for gnu-bug-gnulib@m.gmane.org; Tue, 25 Jan 2011 19:54:29 -0500 Original-Received: from [140.186.70.92] (port=33592 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhteQ-0005Qd-6l for bug-gnulib@gnu.org; Tue, 25 Jan 2011 19:54:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhteP-0003OU-25 for bug-gnulib@gnu.org; Tue, 25 Jan 2011 19:54:22 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:48609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhteO-0003OG-Mk; Tue, 25 Jan 2011 19:54:21 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 275AF39E80E1; Tue, 25 Jan 2011 16:54:18 -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 hRteI8n27baK; Tue, 25 Jan 2011 16:54:17 -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 CFE5639E80DC; Tue, 25 Jan 2011 16:54:16 -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: <83ipxcy6xw.fsf@gnu.org> 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:24935 gmane.emacs.devel:134972 Archived-At: On 01/25/11 13:54, Eli Zaretskii wrote: > This makes the entire unpacking procedure extremely > complicated and thus error-prone I don't see why. With GDB it's two commands: djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat djunpack gdb-7.2.tar.gz Why would it be more complicated than that for Emacs? > . Once the remapping is maintained by humans, it becomes unreliable. No, not if it's checked. Surely the check can be automated reliably. > the subdirectories of the Emacs tree will have to be hard-coded in > config.bat, which is yet another source of errors, when a > subdirectory is added or removed. (The alternative, of using a port > of GNU Find, would mean addition of another tool that is not > required today for building Emacs.) That should not be a problem. 'find' is already required to build Emacs; for example, Makefile.in uses it. It is easy to run 'find' as part of the process that makes a distribution, and to put its output into config.bat or the equivalent, so there is no need to run 'find' under MS-DOS. > Perhaps it's possible to solve all this in a satisfactory manner, but > doing so would require a lot of work, I don't think it'd take much work to do the above. I can write scripts to do the check and to do the find, since they can all be done on a standard GNU platform. What else is needed? On 01/25/11 14:06, Eli Zaretskii wrote: > And what about the emacs-25.chg file? Would you expect users to > google for it as well, and copy-paste it into their shell window? No, I would expect users to extract it from the tarball much as is already done with GDB and djunpack.bat. That's simple, and it would work. >> For example, it should be pretty easy to check emacs-25.chg >> automatically; is that done with GDB? > > Yes, it is done. But it doesn't catch all the errors. How is that checking done, and what errors doesn't it catch? I don't see the checking in the GDB 7.2 distribution. > We are talking about renaming files in the Emacs repo. Why would > gnulib developers have any say in that? Because we automatically sync files from gnulib into Emacs. What I think you are suggesting, is that we rename gnulib files, and edit their contents, after copying them from gnulib into Emacs. But this will break the existing "make sync-from-gnulib", or require "make sync-from-gnulib" to be considerably more complicated. The renaming and copying is needed only on MS-DOS; it's not needed for any other platform. It makes sense to do it only on MS-DOS. This will simplify maintenance on non-MS-DOS platforms; for example, it will make it easier to propagate fixes from Emacs back to gnulib. >> Also, the problem of non-8+3 file names does not seem to be limited >> to gnulib-derived files. > > Yes, they are limited to gnulib-derived files. If you mean Org, I'm > sure those files will be renamed. I meant all the other files that have 8+3 issues. These are all problems, even if the solutions differ for different cases. > Who is "we" here, I wonder. I can write the above scripts for Emacs. The ideas can be propagated into GDB later, as needed.