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: msdev chokes on .dsp and .dsw in unix text file format
Date Sat, 20 Nov 2004 03:53:23 GMT
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

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.


View raw message