apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: WIN32: save MSVC files with CR+LF?
Date Sun, 29 Aug 2004 01:31:18 GMT
At 03:02 PM 8/28/2004, Cliff Woolley wrote:

>Normally Bill Rowe will come along behind and build a .zip of the
>distribution that was checked out using a Win32 version of CVS so that
>*all* of the files have DOS line endings.  The .tar.gz and .tar.Z
>distributions always have unix line endings.

Actually, apr/build/lineends.pl will do that nicely for anyone
who has perl installed, even from the .tar.gz's :)

To Klaus's comments;

>On Sat, 28 Aug 2004, Klaus Keppler wrote:
>> Suggestion: the following MSVC files should be saved with
>> CR+LF (if that's possible?), so you can open them out-of-the-box
>> with Visual C++ 6.0. Actually you always have to convert these files
>> right after unpacking the archive file.

The .dsp / .dsw / .mak files you mention are only a handful
of the TEXT FILES we distribute with the package.

Unix filesystems have \n lineends.  Win32 has \r\n endings.
Anyone who wants to contend with a mishmash has my blessing
on their system but not in our repository!

Why do I shake violently at fools who commit such files as
binary \r\n line endings?  My reasons are really trivial, and
result in massive wastes of time for me.  I maintain dozens 
of patches across platforms which, checked out under unix, 
neatly patch the unix text files.  These same patches also 
neatly apply when checked out with dos line endings, to dos 
files on windows.  Now - if you work with native files on unix, 
and then attempt to cvs diff this garbage, you end up with 100%
deltas of the files.  The bigest offenders are tomcat and php,
I frequently have two-line patches to the .dsp files to change
library/include paths to my locally employed path envvars.
There is no way for me to maintain such patches for both 
platforms without extra passes through lineends.pl, and then
rerunning the files several times to get the cvs diff out of
the picture.  On top of this mess, I've frequently seen "TEXT"
files in cvs with \r\n endings on unix, which check out under
windows cvs as \r\r\n.  EWWWW.

If you are win32'er using cvs, why on earth would you use a port
of cvs-like utilities which check out text as \n?  If you are
a cygwin'er, you use \n text exclusively, you aren't using silly
MS tools to ever handle those files (right?)

As far as tarballs, httpd and apr toss up a corresponding .zip 
files in the process, identical to the unix .tar.gz, with
the exceptions 1) unix line endings, 2) win32 visual studio 5.0
makefiles (because that version couldn't do command line builds
from .dsp files), and 3) some files generated from awk/sed/bison
that the user might not be able to generate without extra utilities.

>> If that's not possible, a small notice in the docs would certainly
>> help other people ;-)

Seeing as we offer the tool for the job (apr/build/lineends.pl) that
sounds like a wonderful idea!  Working on a compiling_win32.html fix
right now.


View raw message