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: 20 Jul 2003 11:46:08 -0700

"Eli Zaretskii" <eliz@elta.co.il> wrote in message 
news:<mailman.216.1058129750.496.help-gnu-emacs@gnu.org>...
> > From: bart.oldeman@bristol.ac.uk (Bart Oldeman)
> > Newsgroups: gnu.emacs.help
> > Date: 1 Jul 2003 04:00:17 -0700
> > > 
> > > 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
> 
> No, it isn't: suppose you then prepare a tarball of the distribution,
> and that tarball needs to be built on Windows using those batch files.
> (This is an actual problem with Emacs, for example.)

what you are "supposed" to do then it to do on the fly eol conversion
-- the source code for Windows then uses CRLF for all text files and
not just batch files. Like the "-l" option of InfoZIP's zip.

Staying with the philosophy of "different platforms, different text
file formats"...

It's just that emacs wants to distribute *one* source tarball for all
platforms that makes this a problem. In CVS's way of thinking one
would produce, say, a .tar.gz for Unix with LF line endings, a zip for
Windows with cr-lf line endings, another format for VMS and so on...

Somebody submitted a patch to the CVS developers a couple of years ago
that can make the cvs client on Unix behave like one on Win32 and vice
versa. The CVS developers didn't like it. With this status quo there
doesn't seem to be a good solution in sight.

patch:
http://www.geocrawler.com/archives/3/383/2000/12/0/4826403/
reply from Larry Jones
http://www.geocrawler.com/archives/3/383/2000/12/0/4826709/

Not that I disagree with you about making one source tarball -- this
is just something to be careful about (particularly if you start using
$Log in batch files -- you'll see that the server will add LF line
endings).


Bart


reply via email to

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