Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41B90625.3050707@xbc.nu>
Date: Fri, 10 Dec 2004 03:12:53 +0100
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: dev@apr.apache.org
Subject: Re: Compilation on Windows
References: <41B882A8.4060100@lri.fr> <41B8C6C4.3000805@xbc.nu>
 <6.2.0.14.2.20041209161518.04af7db8@pop3.rowe-clan.net>
 <41B8D564.7060503@xbc.nu>
 <6.2.0.14.2.20041209173111.05d85958@pop3.rowe-clan.net>
In-Reply-To: <6.2.0.14.2.20041209173111.05d85958@pop3.rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

William A. Rowe, Jr. wrote:

>At 04:44 PM 12/9/2004, Branko ÄŒibej wrote:
>  
>
>>>* because 'patch' should always 'just work'
>>>
>>>      
>>>
>>It has for me. I've not yet seen a version of patch (on Unix) that would get confused by the CRs.
>>    
>>
>
>Apparently you don't do AIX 4.3, HP/UX and other twisted
>varients lol.
>  
>
As a matter of fact, I do. Yet I have seen no such problems. But I admit 
I use Emacs everywhere, and the rest of the world isn't so enlightened. :-)

>>>* because other platform maintainers may add/delete sources
>>>      
>>>
>>So? They can use a non-broken editor, such as Emacs, vim, etc.
>>    
>>
>It's unix'es editors job to recognize silly MS conventions?
>  
>
I consider any editor that doesn't maintain a file's end-of-line style 
to be broken, whether on Unix or elsewhere.

>>>* because .dsp/.dsw are only the 'obvious' problem.  The less
>>>obvious issue is that the compiler gets entirely twisted about
>>>what 'line number' of the sources corresponds to a given
>>>symbol, and the debugging support becomes worthless with \n
>>>terminated sources.
>>>      
>>>
>>Huh? Which compiler? And what does that have to do with the 
>>format of .dsp files?
>>    
>>
>
>Has to do with the format of all text files built by MS cl.
>
>A broken build is a broken build, whether it just won't build
>at all, or when the build results are mildly bogus by being
>impossible to debug/trace etc.
>  
>
I still don't understand what the problem is. I've built files with MS 
cl that contain \n instead of \r\n, and I've never noticed anything 
wrong with the debug info.

>I'm coming to learn that, though I'm still not reassured.
>
>Better point though; svn unix users (or the cygwin port users)
>can add a flag to their checkout to grab files as CRLF.  There's
>no need to even use the win32 svn port to accomplish this.
>  
>
Yes but that will affect _all_ text files, which might not be what you want.

>>I'd like to see concrete examples of problems that can't be worked around. This hand-waving and inventing problems bores me. I've been using Subversion with CRLF eol-style set on .dsp files for years, from both Windows and Unix, and I've never had a single problem.
>>    
>>
>
>I deal with about 6 different 'edgy' unicies, which aren't
>nearly as forgiving as Linux.
>
>There are alot of broken projects which focus only on the expected
>Linux/OSX/Win32/Solaris8+ and don't even know what an .sl file is,
>year old projects who can't grok .dylib files, etc... while our 
>APR project attempts to be wildly more cross platform.
>  
>
Well, we can hope. :-)

>Simple fact (again, cvs, and svn may prove better) - In order to
>patch mixed source and .dsp files as one update against, say,
>cvs-php4, it's impossible to apply the same patch, checked out
>on hpux, linux, solaris, and win32.  It works just dandy on win32,
>they all come out with cr/lf's, patches included.  Try that on
>hpux for example, and it chokes.
>  
>
Such cross-platform patches will always be a problem, and they really 
have nothing to do with Subversion or the eol-style settings. Possibly 
an "svn patch" command could fix that, but we're quite a ways from that.

>But much worse, try a cvs diff on unix, and you end up with
>a mess of ^M's on the patch.  Now, commit that patch, check
>it out on win32, and you end up with the beautiful CR/CR/LF
>line endings.  This isn't getting any prettier.
>  
>
Yes, this happens with CVS. Like I said, SVN is quite a bit smarter than 
that. If you set the svn:eol-style property, it won't let you commit 
unless the file's contents conform to what that prop says they should be.

>SVN has it's own issues.  Do an svn diff of a text file (native.)
>Guess what?  The resulting patch isn't even native!  On win32
>I'm left with LF delimited deltas.
>
Huh? Which version of SVN? I think we fixed that bug a while ago. If 
not, tell us about it. Please. :-)

>  Obviously, I won't be ditching 
>lineends.pl any time soon.
>
>The cli-dev@httpd project's httpd/mod_aspdotnet repository is
>actually a nice place to play with these issues; we only build
>that module on Win32, so almost every issue I mentioned is moot.
>I'm struggling to see how svn is helping us and what it can do 
>to seriously help Win32 users.
>  
>
-- Brane