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: Compilation on Windows
Date Thu, 09 Dec 2004 23:47:30 GMT
At 04:44 PM 12/9/2004, Branko Čibej wrote:
>William A. Rowe, Jr. wrote:
>
>>At 03:42 PM 12/9/2004, Branko Čibej wrote:
>> 
>>>Tangui Morlier wrote:
>>>
>>>By the way, folks, why on earth do those files have svn:eol-style set to "native"
instead of "CRLF"?
>>
>>* because they contain text
>What's that have to do with the end-of-line style?

Yes most linux editors, at least recent ones, recognize dos
line endings.  But those are not linux text files, and on older
OS's - they become harder to maintain.

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

>>* 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?

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

>>apr/lineends.pl exists for this purpose.
>It existed for this purpose while we were using CVS. Many people argued against putting
the -kb flag on DSP files, and I sort of agree with that. However, Subversion is quite a bit
smarter than CVS.

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.

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

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.

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.

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

Bill



Mime
View raw message