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:23:56 GMT
At 09:14 PM 11/19/2004, Garrett Rooney wrote:
>William A. Rowe, Jr. wrote:
>
>>ONLY if svn:eol-style crlf in conjunction with an svn diff produces
>>an identical result on linux and win32.  Even then it creates a
>>binary diff (mixing line ending codes).  This is -not- elegant.
>>Search for my previous rants on the subject.
>
>I'm not sure exactly what the behavior is, but I will note that nobody
>has seemed to have a problem with using svn:eol-style on these kind of
>files in the Subversion tree.  If there is a problem with the way it
>currently works I'm sure the Subversion dev list would like to hear
>about it.  If there have been discussions about such things in the past
>that were ignored then a reminder of the issues involved would probably
>help get them dealt with.

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.

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

Bill 


Mime
View raw message