Feature Requests item #1853440, was opened at 2007-12-18 21:30
Message generated for change (Comment added) made by vadz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=359863&aid=1853440&group_id=9863
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Priority: 3
Private: No
Submitted By: troelsk (troelsk)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn line endings
Initial Comment:
"What you cannot do it tell SVN what the default line ending is for your checkout. Not a problem usually, expect where you checkout on win32 into a samba share for use on Unix"
(http://svn.haxx.se/users/archive-2003-10/0409.shtml)
Indeed, if you do this (use a Windows checkout from Linux), configure etc fails with ^M.
Please consider using this cvs setup:
[auto-props]
* = svn:eol-style=LF <-------
*.h = svn:eol-style=native
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
Notes:
- This could be opening up a can of worms?
- To be able to control this at checkout would be much to be preferred, but this appears to be impossible judging from the (quite old) post above.
----------------------------------------------------------------------
>Comment By: Vadim Zeitlin (vadz)
Date: 2008-01-02 17:45
Message:
Logged In: YES
user_id=71618
Originator: NO
No, I have separate wx check outs on all machines (well, a shared one for
all Unix machines exported via NFS but a different one for Windows). When
you have a patch you just do "svn di > my.diff" and then apply the patch to
the other tree (and then revert it).
----------------------------------------------------------------------
Comment By: troelsk (troelsk)
Date: 2008-01-02 17:39
Message:
Logged In: YES
user_id=1290727
Originator: YES
>You will have to do the translation locally.
So be it. I wonder what other people do when, say, preparing a patch for
wxWidgets, needing to test it first on several platforms. Don't you always
need one single copy of wxWidgets to patch on/against, across platforms, to
be able to compile and test a patch?
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2008-01-01 20:59
Message:
Logged In: YES
user_id=71618
Originator: NO
I don't want to revert the changes already done (there is no harm done)
but I still don't want to use LF instead of native for the source files,
this is just wrong for Windows-based people. You will have to do the
translation locally.
----------------------------------------------------------------------
Comment By: troelsk (troelsk)
Date: 2007-12-31 13:01
Message:
Logged In: YES
user_id=1290727
Originator: YES
Many thanks Stefan, your explanation makes things clear. Amazing that gcc4
on Unix is broken like this, not capable of handling different line
endings.
>I guess, the 2.8 file release you're referencing is one of those packed
on a Unix platform
Indeed, it's the wxAll file release (wxWidgets-2.8.7.zip).
The wxAll file release is the cure-all for all my setups, it compiles
clean 'everywhere' (VC6-9, MinGW, gcc4 on Unix/Ubuntu/andLinux).
Chris Elliot got the line endings just right:
LF everywhere, except in .dsp and .dsw files (CRLF).
svn is not versatile to this extent, because of the annoying
eol-style=native 'feature', you cannot share one single checkout between
Windows and Unix.
I propose this:
1. Roll back r50858 and r50845, they aren't doing any good, sorry
2. cvs setup almost like originally proposed (above), to facilitate
sharing one single checkout between Windows and Unix
[auto-props]
* = svn:eol-style=LF
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
(Could there be some Windows compilers left not capable of reading LF
files? Borland? Digital Mars?)
----------------------------------------------------------------------
Comment By: Stefan Neis (neis)
Date: 2007-12-21 12:57
Message:
Logged In: YES
user_id=32202
Originator: NO
I think the problem is that by downloading via Windows, your .c and .h
files get native (i.e. windows like) line endings, which gcc on Unix just
doesn't like when they occur in macros (stuff like "#define something
whatever" where "whatever is distributed over multiple lines, using "\").
The only workaround I see is to either always use "LF" as eol-style for
these files (with the obvious consequences to everybody using one of the
bad editors like notepad provided by Windows; note that Visual Studio and
notably the compiler cope just fine with the "LF"-only line endings) or
download it via Unix (so you still get the "LF" line endings, but that
choice affects only you). I guess, the 2.8 file release you're referencing
is one of those packed on a Unix platform (i.e. not "wxMSW*.zip" or are
there any others using windows' eol convention?).
----------------------------------------------------------------------
Comment By: troelsk (troelsk)
Date: 2007-12-20 18:33
Message:
Logged In: YES
user_id=1290727
Originator: YES
Many thanks! configure makes it to the end now, it looks good (config.log
attachment).
Unfortunately make runs into trouble early on.
andLinux:/home/wx29/buildgtk2d# make
...
/mnt/wx29/trunk/src/regex/regcomp.c
In file included from /mnt/wx29/trunk/src/regex/regcustom.h:39,
from /mnt/wx29/trunk/src/regex/regguts.h:38,
from /mnt/wx29/trunk/src/regex/regcomp.c:33:
/mnt/wx29/trunk/include/wx/defs.h:914: error: zero width for bit-field
'Wchar_tMustBeExactly2Bytes'
In file included from /mnt/wx29/trunk/src/regex/regcustom.h:39,
from /mnt/wx29/trunk/src/regex/regguts.h:38,
from /mnt/wx29/trunk/src/regex/regcomp.c:33:
/mnt/wx29/trunk/include/wx/defs.h:952:5: warning: "SIZEOF_LONG" is not
defined
In file included from /mnt/wx29/trunk/src/regex/regcomp.c:2179:
/mnt/wx29/trunk/src/regex/regc_locale.c: In function 'element':
/mnt/wx29/trunk/src/regex/regc_locale.c:706: warning: implicit declaration
of function 'wcsncmp'
make: *** [wxregex_regcomp.o] Error 1
- If I checkout svn trunk inside the Linux box (instead of using the
Windows share /mnt/wx29) I see no problems, everything works fine.
- If I use the wx2.8 file release (/mnt/wx28), also shared between Windows
and andLinux, everything works fine too, on both platforms.
If this (final?) problem is solved, this andLinux/colinux build setup is
super-great (esp for people not too familiar with Linux), and perhaps
deserving a mention in the wiki.
(It better wait until the next andLinux release though, andLinux has
become somewhat out of sync with the default repos it is preconfigured
with)
File Added: config.log
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2007-12-20 13:03
Message:
Logged In: YES
user_id=71618
Originator: NO
Changed to LF for these files too, thanks.
As for Cygwin, I'm pretty sure its bash dislikes shell scripts in DOS
format. I'm rather surprised to hear that it works for you, but well.
----------------------------------------------------------------------
Comment By: troelsk (troelsk)
Date: 2007-12-20 12:12
Message:
Logged In: YES
user_id=1290727
Originator: YES
Many thanks! trunk/configure is good.
These are still native, not LF, fails:
src/expat/configure
src/expat/configure.in
src/png/configure
src/tiff/configure
src/tiff/configure.ac
>r50845...use LF style for Unix files which don't work under Cygwin if
they have CR LF
In fact Cygwin is fine I believe. The problem is the Linux configure tool,
it fails on CRLF. This (line ending) problem comes when checking out wx in
a single shared folder, for use by both Windows and Linux. The configure
tool really should be more forgiving.
I think this (sharing a wx copy) will work if the configure files above
too are forced to LF.
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2007-12-20 02:05
Message:
Logged In: YES
user_id=71618
Originator: NO
Done, let's see if we have any problems.
----------------------------------------------------------------------
Comment By: troelsk (troelsk)
Date: 2007-12-19 16:06
Message:
Logged In: YES
user_id=1290727
Originator: YES
>But we could indeed probably set it for config*, *.m4 and
>{autogen.,install-}sh
Good solution, less heavyhanded, please consider doing it.
Thanks
(A workaround, a painful unpleasant one:
http://snippets.dzone.com/tag/dos2unix)
----------------------------------------------------------------------
Comment By: Vadim Zeitlin (vadz)
Date: 2007-12-19 00:06
Message:
Logged In: YES
user_id=71618
Originator: NO
It's definitely not a good idea to set eol-style to LF for everything by
default. But we could indeed probably set it for config*, *.m4 and
{autogen.,install-}sh. Do we need it for anything else?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=359863&aid=1853440&group_id=9863