We have a really annoying issue with saving the .jucer project via the Projucer app. Sometimes (seemingly randomly), the app decides to reformat the entire .jucer file after saving. Inserting line breaks, rearranging attribute order, stuff like that.
It makes merge conflicts absolutely horrible to resolve, especially when the actual changes in the .jucer file are not trivial.
Our team is using the exact same Projucer binary, yet the behaviour is inconsistent across team members - one member might modify the .jucer file and it would insert line breaks, while the other might pull those changes, save the .jucer file and it would remove the line breaks.
Does anyone know what’s causing this and how I can possibly make it consistent across the team?
Thanks in advance!
before you save the project from the Projucer, either by selecting File > Save or by clicking the Save and Open in IDE icon, make sure to close all the open source code files by selecting Document > Close All Documents from the menu bar. It’s annoying, I know…
Oh damn, I misread your question: you’re actually seeing the jucer file getting screwed up, not the source files
Maybe it has something to do with line endings… are you all using the same configuration in your version control system?
Hmm, so it might be Git that screws up the line endings for the .jucer file, which in turn confuses the Projucer and makes it rearrange the whole file? I didn’t think about that. I assume we all use AutoCRLF but will check with the team.
I don’t know that we’ve ever cared what exactly changed in a .jucer file. We just let git update it. (And any time it changes, I throw out my Builds and JuceLibraryCode folders before regenerating from Projucer, just to be sure we get everything we need regenerated.)
Is this behavior actually breaking anything?
This can occur if some team members are using Windows and others Linux or macOS. You might work around this by deciding on which convention you’d prefer, and add a git pre-commit hook to format the file with the line ending type you prefer.
The line ending is actually a setting inside the Projucer project, so regardless of windows, mac or linux, it should use consistent line endings and it does in my experience.
The problem seems to be that XML doesn’t specify the order of attributes, they have to be expected in random order.
I do the same like @HowardAntares, when there was a change, I checkout
theirs, apply my changes and commit it.
Luckily project settings don’t change that often, most times it is adding or removing files, which git handles quite well with jucer files in my experience.
It’s definitely not about OS, we all work on the same platform.
It’s not “breaking” anything per se but my team have spent many long hours over the years resolving these merge conflicts. It can be very annoying and is a waste of time.
I’m not sure it’s about line endings, it’s like sometimes it randomly decides to wrap all lines in the file:
Can you spot what actually changed here? (spoiler: nothing at all, a new file was added about 500 lines before)
This file has 700 lines and are all marked as changed by Git (“ignore whitespace” doesn’t help here).
Of course I can just checkout
theirs and apply my changes, but for more complicated conflicts it can take some time and it does add up. It also breaks my flow and makes me annoyed.
I just don’t understand why Projucer needs to do this at all and I want to turn this behaviour off.
I am 100% with you.
Unfortunately I don’t have a solution, I was just pointing out that both is valid XML as a side note,
and like you also think that it’s not the line endings, because it is setup per project within the jucer file.
The issue is in XmlElement’s TextFormat. Here you can setup the wordwrap length:
However I have no idea why this is inconsistent amongst your team…
In the code you can see, it uses a default XmlElement::TextFormat, just setting the newline character:
Setting a consistent value for
lineWrapLength might help, I don’t know if there was a change at some point.
But I wonder, if there is another place in the code, that also writes the jucer file with different defaults.
Searching for TextFormat in Projucer didn’t suggest that though…
The weird thing is that the length of the lines added doesn’t seem to matter for Projucer when it decides whether or not it wants to reformat the entire file.
In the project that it just happened, we have had lines above 200 characters for over a year. The modification that caused the reformat to happen added a single line that’s not even the longest in the XML block that it’s in.
Like I said, I assume there is an alternative code path that saves the file. But I have no proof.
But I have to leave you here, I was just curious and looked into the sources…
Why not just pretty-print the .jucer xml file before checkin, and give everyone the same pretty-print tools?
All my jucer projects get run through Python to update paths and other settings. I run it before every commit and it has to the nice side effect of keeping jucer files pretty printed consistently.
So that’s one example solution.
Thanks @austrianaudioJV and @caustik for the simple workaround idea, I’m gonna probably just implement this