From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel,gmane.comp.lib.gnulib.bugs Subject: Re: Files from gnulib Date: Thu, 27 Jan 2011 00:32:03 -0800 Organization: UCLA Computer Science Department Message-ID: <4D412D83.1010503@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> 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 1296117574 19733 80.91.229.12 (27 Jan 2011 08:39:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Jan 2011 08:39:34 +0000 (UTC) Cc: cyd@stupidchicken.com, bug-gnulib@gnu.org, 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 Thu Jan 27 09:39:28 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 1PiNO4-0005G3-CF for ged-emacs-devel@m.gmane.org; Thu, 27 Jan 2011 09:39:28 +0100 Original-Received: from localhost ([127.0.0.1]:60919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiNHD-0003cF-De for ged-emacs-devel@m.gmane.org; Thu, 27 Jan 2011 03:32:23 -0500 Original-Received: from [140.186.70.92] (port=54844 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiNH3-0003ZJ-V6 for emacs-devel@gnu.org; Thu, 27 Jan 2011 03:32:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiNH2-0006yw-Nu for emacs-devel@gnu.org; Thu, 27 Jan 2011 03:32:13 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:37313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiNGy-0006yA-13; Thu, 27 Jan 2011 03:32:08 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C08DE39E80E0; Thu, 27 Jan 2011 00:32:05 -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 vRsH3yCY9B8g; Thu, 27 Jan 2011 00:32:04 -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 60A9E39E80DB; Thu, 27 Jan 2011 00:32:04 -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: <83d3nkxq31.fsf@gnu.org> 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:135080 gmane.comp.lib.gnulib.bugs:25011 Archived-At: On 01/25/2011 08:10 PM, Eli Zaretskii wrote: > It's done by the ARI script. All I know about the errors is that some > files still clash. I looked into that, and the ARI script itself doesn't know anything about 8+3 file names, so some other program must be doing it. My guess is that they're using GNU doschk and filtering the output. If I run "make dist" on the Emacs trunk, and then ask GNU doschk to report all 8+3 file name clashes in the resulting distribution, it reports the following: ORG-COMP.EL : ./lisp/org/org-compat.el ./lisp/org/org-complete.el ORG-COMP.ELC : ./lisp/org/org-compat.elc ./lisp/org/org-complete.elc SEMANTIC.EL : ./test/cedet/semantic-ia-utest.el ./test/cedet/semantic-tests.el ./test/cedet/semantic-utest-c.el ./test/cedet/semantic-utest.el TESTSPPR.C : ./test/cedet/tests/testsppreplace.c ./test/cedet/tests/testsppreplaced.c Do you see any errors in this report? If so, we should fix GNU doschk. If not, that suggests that doschk is good enough for us to use with Emacs, as part of a maintainer-mode check for problems in this area. >> From: Paul Eggert >> 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? Having MS-DOS builders type two commands to extract, rather than one, is not complicated. It would be a tiny price to pay, compared to the hassles for all developers who have to shoehorn file names into the 8+3 straitjacket. People who build for MS-DOS can be expected to understand minor workarounds like this. > And how about the issue with using slashes in the > argument to djunpack? What issue is that? In the above instructions, djunpack's argument does not contain any slashes. > Scripts are written by people, who tend to err or miss something. Sure, but a reasonable script will greatly lower the error rate to something that is manageable. That's all that one can ask of any build system. >> '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). No, 'find' is used in other places too; for example it is used the top level Makefile.in, and in leim/Makefile.in. But my point, which I think you're agreeing with, is that it's OK to use 'find' in maintainer 'make' rules, since maintainers are expected to have hosts with a decent toolset. > 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. That's OK. It's normal, even on Unix-like hosts to do that. I do it all the time. I've caught multiple bugs recently in Emacs by doing that. The goal is not to make _maintenance_ practical on MS-DOS; that would be far too ambitious. The goal is only to make _building_ practical on MS-DOS. >> What else is needed? > > Maintenance. No matter what solution we adopt, some maintenance will be required. However, if we can automate most of it, we will lessen the overall maintenance burden. > How can instructions that need to be googled for be simple and > reliable? Instructions don't *need* to be Googled for. One can visit the Emacs web page, and navigate to the installation instructions, which will be one of the web pages that I mentioned. However, it is quite common to use Google nowadays, more common than traditional navigation, and there's nothing wrong with that. >>>> 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? CEDET as well (see the above). This is a continuing issue, with files coming from multiple sources, and the problem is likely to keep cropping up. We need a better solution than what we've got now.