From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Bootstrap fails on w32 Date: Mon, 23 May 2005 10:46:08 +0200 Message-ID: <85mzqmjpnz.fsf@lola.goethe.zz> References: <428FB183.3000209@student.lu.se> <4290EDA8.7020401@student.lu.se> <85psvjyli5.fsf@lola.goethe.zz> <85acmmlwqc.fsf@lola.goethe.zz> <85r7fykdbo.fsf@lola.goethe.zz> <01c55f4a$Blat.v2.4$8153d260@zahav.net.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1116845065 22983 80.91.229.2 (23 May 2005 10:44:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 May 2005 10:44:25 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 23 12:44:15 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DaAPT-000169-AG for ged-emacs-devel@m.gmane.org; Mon, 23 May 2005 12:43:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DaASu-0005US-IC for ged-emacs-devel@m.gmane.org; Mon, 23 May 2005 06:47:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DaA4w-00088S-Lk for emacs-devel@gnu.org; Mon, 23 May 2005 06:22:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DaA4t-00087V-W0 for emacs-devel@gnu.org; Mon, 23 May 2005 06:22:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DaA2V-0006UO-QK for emacs-devel@gnu.org; Mon, 23 May 2005 06:20:04 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Da9iw-0007GB-BK for emacs-devel@gnu.org; Mon, 23 May 2005 05:59:50 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Da9Yp-0000Bc-BM; Mon, 23 May 2005 05:49:23 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id AF7CA1CE2C7F; Mon, 23 May 2005 10:46:09 +0200 (CEST) Original-To: Eli Zaretskii In-Reply-To: <01c55f4a$Blat.v2.4$8153d260@zahav.net.il> (Eli Zaretskii's message of "Mon, 23 May 2005 06:49:02 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:37508 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37508 "Eli Zaretskii" writes: >> From: David Kastrup >> Date: Mon, 23 May 2005 02:15:07 +0200 >> Cc: Lennart Borgman , emacs-devel@gnu.org >> >> > There is no such thing as a "Windows release" of Emacs. There are >> > binary builds for Windows, but the source they are built from is >> > the same as every other platform. >> >> Apart from the line endings. Or something. > > No, not ``apart from''. Precisely the same sources. The Emacs > tarball as distributed by ftp.gnu.org needs to be buildable on a > Windows machine. That is why several files, such as batch files, > need to have DOS EOLs, because otherwise Windows tools might barf. > For example, stock shells on some Windows versions would not run a > batch file with Unix EOLs (although I find that Windows XP's CMD was > silently fixed to remove this misfeature, as well as a few others). The problem is that all of those files are text files, and quite a few tools do end of line conversion on them. I am probably more obnoxious than usual about this issue because I am trying to resolve what to do about AUCTeX and the recommendations for unpacking. AUCTeX contains also TeX source files, and some of the are converted by Perl script and similar. Now the Perl documentation is pretty clear that it does end-of-line conversion in Windows on read&write when processing files that are not explicitly opened in binary mode. Since we both read and write the files in question and use \n in the patterns for reading and writing, this affects us, and the natural consequence would be to recommend using the Windows conventions when unpacking. The error reports we get, however, are suggesting that exactly that makes Perl barf. Maybe it has something to do with what compilation of Perl is used (Cygwin could be different?). And also "makeinfo" seemingly formats junk when presented with DOS line endings, even though it is supposed to be a text tool. I just don't get it, and that's why I am trying to see what others do. The "solution" text checkout for editing, binary for compilation is, I must say, an idea I find appalling rather than appealing. I did not think of that before the discussion, and I actually find that I would want to avoid such recommendations unless completely unavoidable. Which might be the case, unfortunately. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum