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. E.
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.
Bill
