[En-Nut-Discussion] New Makefile Structure
uprinz2 at netscape.net
Wed Apr 15 11:52:20 CEST 2009
> VS will detect the unix line ending and offer to fix them (or not).
> I'm sure Eclipse should work just as well.
Yes it will fix it, but convert if to windows style. So with a commit
everything will hve windows endings.
AFAIK with good ports of gnu utils on windows it is no problem to have
linux endings on windows. But it is big trouble to have windows engings on
linux with the same but unported gnu tools. So I use only linux endings on
all gnu utility based projects i.e. AVR, ARM, RISC-X.
The svn:eol-style native does only partly fix the problem. I use nutos in a
mixed enviroment. So some collegues compile und linux, some under windows
and I have to do both. Checking out with TortoiseSVN under windows to a
samba share on linux and then trying to compile under linux will fail with
native line endings. So I have to check out twice, one repos for windows
compatibility tests and one for linux.
I think the only straight solution is to nail the line endings to one fixed
type and advice all users of other enviroments to use the native option.
A short excerpt from the svn-book will tell:
This causes the file to contain the EOL markers that are native to the
operating system on which Subversion was run. In other words, if a user on
a Windows machine checks out a working copy that contains a file with an
svn:eol-style property set to native, that file will contain CRLF EOL
markers. A Unix user checking out a working copy which contains the same
file will see LF EOL markers in his copy of the file.
Note that Subversion will actually store the file in the repository
using normalized LF EOL markers regardless of the operating system. This is
basically transparent to the user, though.
Especially the last sentence is important. So if there are no mixed line
endings in one file, differences in line endings will not cause the
repository to grow without need.
Best regards, Ulrich
More information about the En-Nut-Discussion