William A. Rowe, Jr. wrote:
Simple. Let me suggest a patch containing
libapr.dsp apr.dsp build/config.m4
that effects some change to the build, for private build purposes.
Now, imagine trying to svn co such a patch, and have it apply, on both win32 and unix without missing a beat.
When all TEXT files are native eol-style, this just works. When checked out on win32 native, the patch and to-be-patched files all have matching line ends. When checked out unix native, the patch and to-be-patched files all have matching line ends.
It only becomes a NIGHTMARE when folks believe that a unix utility should be used for checkouts to win32. Not only do the .dsp, .dsw, makefiles and .vcproj/.sln files all fail, but there are much more subtle errors in the compilation of code, such that later debugging information doesn't line up with actual lines of code. It's very exasperating and a total waste of time to decipher segfaults that result in such code.
I've always maintained that to build win32, one uses win32 files. To build unix (including cygwin) one uses unix files. And to check out from a repository, one uses the native svn to the target.
I love the spirit, concept, and even occasionally the implementation of cygwin. But it drives me mad to have folks expect cygwin and native win32 results correspond with one another. They are most certainly two different platforms.
So are you saying that if we force svn:eol-style to CRLF on the .dsp files that the resulting patches won't work. When I try it here (a unix box) I get a diff that includes \rs at the end of the lines for changes in a CRLF file. Isn't that what it should be? Patch seems to deal with it just fine BTW, even if there are some CRLF and some NL files.
I admit, I haven't tried this on win32 (either normal or cygwin), since I don't have access to such a machine at the moment, but I have no reason to believe it will work differently there.
Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree.
This, of course, is a marvelous idea.
Unfortunately it requires someone with more Win32-fu than me to do it.
-garrett
