From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Files from gnulib Date: Thu, 27 Jan 2011 06:08:14 -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> <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> <4D412D83.1010503@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1296126584 8728 80.91.229.12 (27 Jan 2011 11:09:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Jan 2011 11:09:44 +0000 (UTC) Cc: cyd@stupidchicken.com, 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 Thu Jan 27 12:09:39 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 1PiPjM-0003Ff-HW for ged-emacs-devel@m.gmane.org; Thu, 27 Jan 2011 12:09:36 +0100 Original-Received: from localhost ([127.0.0.1]:38551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiPjL-0001eA-Ea for ged-emacs-devel@m.gmane.org; Thu, 27 Jan 2011 06:09:35 -0500 Original-Received: from [140.186.70.92] (port=35004 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiPi8-0001Il-7V for emacs-devel@gnu.org; Thu, 27 Jan 2011 06:08:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiPi6-00031A-Gs for emacs-devel@gnu.org; Thu, 27 Jan 2011 06:08:19 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:34671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiPi6-00030z-Er for emacs-devel@gnu.org; Thu, 27 Jan 2011 06:08:18 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PiPi2-0000ww-10; Thu, 27 Jan 2011 06:08:14 -0500 In-reply-to: <4D412D83.1010503@cs.ucla.edu> (message from Paul Eggert on Thu, 27 Jan 2011 00:32:03 -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:135097 Archived-At: Note: I removed gnulib from the list of addressees, as this is no longer a gnulib issue. > Date: Thu, 27 Jan 2011 00:32:03 -0800 > From: Paul Eggert > CC: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > 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. AFAIR, ARI calls doschk, or maybe there was some wrapper script that did that. But doschk is definitely used for this. > 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 I emailed the Org mode maintainers yesterday (off-list), and they agreed to rename org-complete.el to org-pcomplete.el (which is a more correct name anyway, IMO). The Emacs trunk will get that change when it is sync'ed with Org next time. > 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 These clashes are not important, because the test suite should not be part of the release tarball. (I know that currently it is, but Stefan said that this is a bug that should be fixed.) > 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. doschk is definitely good enough. I do run doschk from time to time, and it seemed to be frequently enough. The issue is only important when a release is close. In any case, the problem is not with having a Make target (the command is trivial), but to arrange for someone or something to run it and report the results. Frankly, I never pushed that issue because people tend to get annoyed by 8+3, so having something automatic that would print messages about that didn't seem like a good idea... > >> 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. I'm not talking about the number of commands, I'm talking about the complexity of the first one and the potential to make mistakes in it. Few DJGPP users even know about the -p and -o switches to djtar. (djtar is generally used with only -x.) If you use the command-line arguments in a different order, chances are the command will not work as intended. I myself need to consult the README when I unpack the GDB tarball, for fear of mistakes (which did happen), and I wrote that stuff! > > 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. The argument could include slashes if the tarball is in a different directory. See the comments near the beginning of djunpack.bat. > >> '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 Not relevant, as the DOS build doesn't use the top-level Makefile.in. See config.bat and msdos/mainmake.v2. > and in leim/Makefile.in Not relevant, since this use in the `install' target which isn't run on DOS (because "make install" in mainmake.v2 installs the binary in-place, under the source tree, and thus doesn't recurse into leim/). > 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. Yes, I agree. However, those comments of mine were to your suggestion to rename the files as part of running config.bat, which is run at configure time on the end-user machines. If you now have something else in mind, those comments are probably not pertinent anymore. > > 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. You don't realize how little time I have to work on Emacs in general and on the MS-DOS port in particular. Each such complication steals precious time that I don't have. The Unix machine I use is fencepost, so copying files involves moving them through the Internet. Which means I cannot do this offline (yes, connectivity problems do happen in my corner of the world) or when fencepost is down, and also slows down things quite a lot even if the connection is in good shape. > > 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. So now I'm supposed to lobby Emacs maintainers to have MS-DOS build instructions on the Web site? We've just heard several people ask when it will be possible to drop the MS-DOS support entirely; how would they react, you think, if I made such a request? I generally tend to avoid unnecessary friction wrt the MS-DOS port; I'm sure you will understand after the experience of this thread. msdos/INSTALL is all I need, thank you. It lies low and out of sight, and doesn't bother anyone. > However, it is quite common to use Google nowadays, more common than > traditional navigation, and there's nothing wrong with that. If you are looking for precise and correct instructions, googling is your enemy, because it brings hits that cannot be guaranteed to be correct. Someone said something a year ago, and it's there forever, even if in the meantime things happened that made it false. Look, it's pointless to try to push further the possibility that Emacs will adopt the same way of unpacking as GDB. I invented that stuff in the first place, but after all these years my experience with it is so bad that I will never agree to have it in Emacs. If the issue of file-name clashes becomes so unbearable for the Emacs developers that they will request that all limitations on file names are unconditionally lifted, it will be easier for me to declare that the MS-DOS port is dead, as soon as the conflicts hit the point where it cannot be handled by simple tricks. > >> I meant all the other files that have 8+3 issues. > > > > Which ones? > > CEDET as well (see the above). Not an issue (see 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. Experience shows that these issues crop up very rarely, although the nervous reactions and the futile prolonged debates make it sound like a grave problem. I'm willing to consider any reasonable solutions to that nonetheless, just not this one, because unlike any others, this one is tested in practice, and it failed that test.