emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bootstrap fails on w32


From: David Kastrup
Subject: Re: Bootstrap fails on w32
Date: Mon, 23 May 2005 10:46:08 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Eli Zaretskii" <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Mon, 23 May 2005 02:15:07 +0200
>> Cc: Lennart Borgman <address@hidden>, address@hidden
>> 
>> > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]