Hey guys/jules,
why does the introducer generate all files with CRLF on osx?
it really makes it a pain with git as I have to end up converting all the generated files to mac format each time the introjucer ran its exports!
should the platform specific line ending be used??
grts,
There’s not really such a thing as “mac format” any more, and every compiler and editor on OSX works just fine with CRLF! I obviously do a lot of dev on all platforms, and I use CRLF in all my files because it works fine everywhere.
Yeah make sure the “carriage” returns all the way to the left before you roll the paper up and type on the next line…
Hey guys,
may I then ask what git crlf settings you have? The recommended setting is to have LF in the repository and CRLF or LF depending on which platform you check out on.
I.e. on Windows:
git config --global core.autocrlf true
git config --global core.safecrlf true
And on Mac:
git config --global core.autocrlf input
git config --global core.safecrlf true
See (among many others):
http://help.github.com/line-endings/
http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/
You probably have core.autocrlf = false, but as far as I read just about everyone recommends NOT doing this.
Or am I missing the obvious?
I have it set to “don’t fuck around with the content of my files”.
Seriously, if I check a file into GIT, I expect to get the same bytes back out again. Anyone who turns on an option that will silently change the files that it gives you is just asking for trouble.
OK, fair enough, but… it would be -I suppose- very easy to in the introjucer generate LF and not CRLF on OSX, right? Or basically use the native endline style on all platforms. For you that wouldn’t make a change at all, but for people who do use the git recommended settings it makes a world of difference.
The whole point of the introjucer is that it creates files that you can use in ALL editors and compilers, on all platforms. The best line-ending for achieving that is CRLF, which in my experience works perfectly everywhere.
Personally, I keep all my code in a shared folder which is used by my Windows, OSX and Linux machines. I may run the introjucer in OSX, and then use the resulting project files from Windows. How could that work if the output of the introjucer was dependent on the OS that it was running in?
OK, but that’s how you work… By having the possibility to change line-endings (native <-> windows) you support the way anyone works…
I guess it’s a feature request and no longer a bug report! 
I understand, but it goes totally against my design strategy for the introjucer - I’ve always gone to a lot of effort to ensure that no matter which platform you run it on, the files it generates are always exactly the same.
Can you explain what exactly would go wrong if you turned off this GIT option and just used CRLF on all platforms? Which tool would fail to understand the files? Because I’ve been building on all these OSes for decades and have never had any line-ending problems. Sounds like this GIT setting is “fixing” problems for you that don’t actually exist.
This is bad, I'll explain why:
When Introjucer/Projucer saves files, it converts them to CRLF ("\r\n", Windows "normal" line endings).
When Xcode saves files, it converts them to LF ("\n", "normal" line endings).
Giving the Projucer a shot, I change the GUI layout, am happy, and get a diff which is huge. Huge diffs make merges/stashes etc impossible and kill the benefits of git. So I have to run "dos2unix" on the file for a reasonable diff. I don't use the Projucer as my only IDE because Xcode has a lot of nicer stuff (completions, navigation, compiler errors) or maybe I'm just used to it.
What "modern" editors, like Atom, do, is preserve the line endings of the file. Let's call it "liberal". Would had been nice if Xcode and Projucer were liberal. However I can't expect Xcode to change because Apple tend to try to force us to do the "right thing" and use the "right" line endings. But maybe at least Introjucer/Projucer can be liberal.
Cheers, Yair
GIT should sort this out for you..?
What we do here is to run a script to normalise all the endings (and strip whitespace) in a folder before committing anything to git - that way we keep everything tidy and consistent, which is important in a project like juce.
FWIW I think we already had this in our FR list for the introjucer, but it's not a huge priority for us.
What we do here is to run a script to normalise all the endings (and strip whitespace) in a folder before committing anything to git - that way we keep everything tidy and consistent, which is important in a project like juce.
I was just looking at JUCE's latest commits through github's interface. And noticed an interesting thing regarding this one: https://github.com/julianstorer/JUCE/commit/99ae5a7668714c084255c020b5760cf30b962b0d
As far as github's concerned, the file was changed completely - all lines deleted and new lines added, and so it will not show a diff.
But running "git show 99ae5a7 -w" reveals that only a few lines actually changed.
Does one have to manually run these scripts? That can sometimes be forgotten.
GIT should sort this out for you..?
In what way? In a previous comment in this thread (#5) you strongly object to one way of doing this, and I wonder what's the recommend way for git to sort this out for me.
I think Timur just messed up that file somehow when he committed it (maybe he had it open in a different text editor by mistake or something). Not a big deal, and I fixed it in the next commit. What problem did it cause you?
What problem did it cause you?
It caused the minor inconvinience of having to run "git show -w" seperately.
It's a very small problem, but small problems add up and together they make programming harder and derail trains of thought..
Anyhow the point in mentioning this commit is not to complain about this specific commit, but just to point out that this "script before commiting" method isn't a perfect solution, and that it would be better if this Intro/Projucer feature didn't require such a method. In our case we'll need to consider "script before commit" if we will use Projucer, and meanwhile while trying it we'll have to manually run "dos2unix/unix2dos"..
Xcode has an option for that... see here. So no need for a script. If you tick that everything should work just as Jules described.
I think in that messed-up commit in question I just didn't have that set correctly.
Â
On the subject of line endings - we have SVG files added as Resource files in Introjucer. When Introjucer generates BinaryData.cpp from these on OS X versus Windows, it does the line endings differently.
For example, BinaryData.cpp generated from Introjucer on Windows:
static const unsigned char temp_binary_data_0[] = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n" "<!-- Generator: Adobe Illustrator 19.2.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->\r\n"
Same Resource generated from Introjucer on Mac:
static const unsigned char temp_binary_data_0[] = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n" "<!-- Generator: Adobe Illustrator 19.2.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->\n"
It would be nice if Introjucer always created the BinaryData.cpp with CRLF, or if it was a global option.
The binary data generator doesn't modify the data at all. Like the name suggests, it just treats it as binary, it makes no attempt to parse the text or change line endings.
Most likely GIT is changing your line endings.
Oh, yes, it must be the GIT that is causing it. Sorry for the noise!
What was the solution to this? Same thing happens to me when I run projucer on windows vs on mac. Binarydata files as well as the auto generated files which look like “JuceLibraryCode/juce_graphics.cpp” all have line endings changed when I look in git diffs?
