At 09:35 PM 11/19/2004, Garrett Rooney wrote: >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?
If you apply that patch using native patch on win32, we have duplicate \r's and that does fail. >Patch seems to deal with it just fine BTW, even if there are some CRLF and >some NL files. Modern versions of patch learned to (mostly) ignore \r's - but when you have oddballs (I'm fighting hp/ux and aix at home, this evening) patch is dirt stupid. >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. Trust - it does. Please consider that the patch itself is pushed and extracted from svn just as the original sources, so \r-ness is very consistent. >>>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. 2c US - I'll invest some effort with you. ITMT the suggestion of using either native Win32 svn or converting with build/lineends.pl is the way to go tonight. Bill
