From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: Files from gnulib Date: Wed, 26 Jan 2011 06:10:26 +0200 Message-ID: <83d3nkxq31.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1296015027 8158 80.91.229.12 (26 Jan 2011 04:10:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 26 Jan 2011 04:10:27 +0000 (UTC) Cc: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Wed Jan 26 05:10:19 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 1Phwi2-0000iw-Ro for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 05:10:19 +0100 Original-Received: from localhost ([127.0.0.1]:32994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phwi2-0003MJ-04 for gnu-bug-gnulib@m.gmane.org; Tue, 25 Jan 2011 23:10:18 -0500 Original-Received: from [140.186.70.92] (port=33995 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phwhs-0003MB-9t for bug-gnulib@gnu.org; Tue, 25 Jan 2011 23:10:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phwhq-0007D2-Es for bug-gnulib@gnu.org; Tue, 25 Jan 2011 23:10:08 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:57268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phwhq-0007Cx-7J; Tue, 25 Jan 2011 23:10:06 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LFM001003K8NU00@a-mtaout23.012.net.il>; Wed, 26 Jan 2011 06:10:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.46.39]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LFM001F13KPHV70@a-mtaout23.012.net.il>; Wed, 26 Jan 2011 06:10:02 +0200 (IST) In-reply-to: <4D3F70B8.3090708@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:24941 gmane.emacs.devel:134982 Archived-At: > Date: Tue, 25 Jan 2011 16:54:16 -0800 > From: Paul Eggert > CC: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > 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? This is the complexity I want to avoid. Don't you think it's complicated enough? And how about the issue with using slashes in the argument to djunpack? does that kind of subtlety mean something to you? > > . Once the remapping is maintained by humans, it becomes unreliable. > > No, not if it's checked. Surely the check can be automated reliably. The reliability of this is determined by the scripts that do it. Scripts are written by people, who tend to err or miss something. > > 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. Only lisp/Makefile.in, which is not used when a release is built on DOS (all the files are already compiled). > 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. More complications. This means, for example, that to test an arbitrary revision of the development tree, I will need to run make-dist on Unix, create a tarball, copy it to a DOS machine, then build, find problems, go back to the Unix machine, etc. > > 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? Maintenance. > > 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. How can instructions that need to be googled for be simple and reliable? > >> 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? It's done by the ARI script. All I know about the errors is that some files still clash. > 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 But the price will be unacceptable complications for MS-DOS. No, thanks, not unless we find a simpler way. > >> 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. Which ones?