Don't change jucerVersion field if no changes were made to jucer project

We store .jucer files in our git repos, while the Builds projects are .gitignored, so to build a project after updating from git we need to create the Xcode/Visual-Studio projects first, which when performed via the Projucer also resaves the .jucer file and if the file was not changed recently it will also bump its jucerVersion field to the latest version.

This causes a minor annoyance of spurious git changes. For example one does git branch other-branch and get error: Your local changes to the following files would be overwritten by checkout: with the change being just the bumped version.

It would be nicer without the annoyance: don’t bump the version, or don’t resave if no changes happened, or separate the project creation from saving.

Yes, this is a major annoyance for us here as well. We mostly code on windows but also build on OSX. Everytime we build on OSX, the .jucer files are modified (line endings, sometimes also xml reflowing) even though the actual content never changes.
This also has implications for pre-build steps that write the git hash, git tag and git status (“dirty”/“clean”) to header files so that they can appear in the about page in the final software. Due to this resaving thing, builds always appear as “dirty” even though the repo is actually clean.

I would suggest the following change:
Resave the file to a temporary place, then load the original file and the resaved file and compare them on an XML level. Then overwrite the original file only if the XML is actually different.

1 Like

Then may I suggest also casting your vote for this feature request? :wink:

2 Likes

I think the reason we don’t have more people complaining about this is that a common workflow is to always resave a project using a Projucer built from exactly the same version of JUCE used in that project. Since we occasionally make changes to how the exporters work, or change some default build settings, this is the only way to get completely reproducible builds. This workflow means that jucerVersion is always already the correct value for the branch you are on.

If you’re not building the Projucer each time, checking the jucerVersion value doesn’t protect you from non-reproducible build changes. I think it’s probably best if we just removed this attribute.

Here’s a commit on the JUCE 6 preview branch with jucerVersion removed and only updating the .jucer file if the saved data is different.

3 Likes

For reproducible builds, I recommend specifying the commit hash with git submodule or equivalent, with the build scripts also building the Projucer before invoking it.

1 Like

FRUT’s Reprojucer and Jucer2Reprojucer rely heavily on this juceVersion attribute in order to reproduce how Projucer worked at a specific version.

I guess I’ll have to find other ways to tune the behavior of Reprojucer… :sweat_smile:

As we don’t synchronise build-altering changes to the Projucer with version numbers then you would only be able to approximate the behaviour using jucerVersion.

Could you instead use JUCE_VERSION in juce_StandardHeader.h? If people are effectively running a different version of the Projucer to the framework they are likely to run into problems.

1 Like

Indeed, it’s always been an approximation of Projucer’s behavior, but it usually works. Here are some examples (they all are links to Reprojucer.cmake):

I could indeed use the information from juce_StandardHeader.h (or from some other files in JUCE) but it is way less convenient than reading this jucerVersion attribute :slightly_smiling_face:

Meeh, this is a breaking change :expressionless:
Then please also remove this attribute when resaving, or freeze it to a fixed version-number.

IMHO its useful to store the current version-number of the Projucer because its the only chance to get the the jucer-File format version which has been used (because there were subtile changes in the past)

I believe that a common practice is to have JUCE as a submodule, build Projucer in your full-build script, and let git keep track of which Projucer you used

I agree with chkn and also vote for keeping the jucerVersion number in the jucer file!

We do that. It would help if people in the team didn’t accidentally open the jucer file in some other version of the projucer tho :slight_smile:

Also if you could have multiple versions of the projucer open at once…!!!

1 Like

+1 and not to open “random” jucer files if I specifically double clicked a jucer file.
It is so hard to get rid of open Projucer windows, like Peter Jackson’s zombies…

That’s why I use only the commandline when I checked out.

2 Likes

The latest version of the Projucer now deletes the jucerVersion attribute, but adds a new integer jucerFormatVersion. When we make changes to how information is stored in .jucer files we will increment jucerFormatVersion, so we are no longer tied to the release cycle of the rest of JUCE.

5 Likes