help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: cvs emacs build fails on Windows XP


From: Bart Oldeman
Subject: Re: cvs emacs build fails on Windows XP
Date: 1 Jul 2003 04:00:17 -0700

"Eli Zaretskii" <eliz@elta.co.il> wrote in message 
news:<mailman.8828.1056857204.21513.help-gnu-emacs@gnu.org>...
> > Newsgroups: gnu.emacs.help
> > From: Timur Aydin <ta@taydin.org>
> > Date: Sat, 28 Jun 2003 17:12:24 +0300
> > 
> > cvs does change line ending according to the underlying platform. This
> > is by design.
> 
> A quite broken design, I'd say.
> 
> > A properly added file will be stored on the cvs server
> > with LF line endings. When checking out, the file will be converted to
> > have CR/LF line endings under windows, LF line endings under unix (no
> > change) and LF/CR line endings uder MAC.
> 
> And what would this do to Widnows *.bat batch files, that are already
> in CR/LF format, and should stay that way (or else some versions of
> Windows shells will refuse to run them), including in the repository?

no, they should have LF endings in the repository. Play with $Log RCS
keywords and you see what I mean. Or make them "binary" using "cvs
admin -kb" but that's strange.

You check batch files out on Windows, LF is converted to CRLF, all
is fine.

You check batch files out on Unix, LF stays LF, and all is fine, because
you cannot run the batch files in Unix anyway (well unless you start
playing with Wine or DOSEMU, but those are different platforms so
then you should use a DOS or Windows CVS client in DOSEMU or Wine).
Then you can *edit* the batch file on Unix with any editor (not just
newer Emacs versions for instance) and LFs stay LFs. Check them in
again, and a Windows CVS client retrieves the batch files and 
has the correct format.

This makes sense especially if you realize that this problem goes
beyond line endings and you think about EBCDIC and VMS.

It just happens to be the case that most DOS and Windows compilers
(but Turbo C 2.01 is an exception for instance) accept C files
with LF line endings, that for Emacs you can enforce a policy of
not changing line endings between client and server.

That's the theory and it makes sense. In practise many people
like to do the "idiotic" thing (according to some of the CVS 
developers, search google if you like) of sharing the same 
working directory among different platforms which is exactly
what Emacs tries to do by providing this one universal source
tarball that is unpacked in binary mode on both Windows and
Unix. So this "idiotic" thing makes sense too :)

Bart


reply via email to

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