apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: msdev chokes on .dsp and .dsw in unix text file format
Date Sat, 20 Nov 2004 03:35:16 GMT
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.


View raw message