Version management vs. Projucer

[raketa]

How can we sensibly control the version numbers that go into recources.rc and the various Info.plist. We have an automatically generated header containing the version number and conversions into various formats.

Usually (in sensible projects without impeding projucer dependencies) such a header gets included in the .rc or with the .plist preprocess. But how do we work around projucers helping hands here?

[anthony-nicholls]

I’ve always found projucer manages the version just fine including in the plist and the include_juce_audio_plugin_client_AU.r resource file. You can also preprocess the plist.

• Click on the Xcode exporter
• Navigate to Custom PList and set your version number field to whatever you want
• Below that set the PList Preprocess field to Enabled
• Below that set the PList Prefix Header field

You could then presumably use a single header to manage your version number? that header could also be included by the AppConfig.h to override any settings in there? does that help?

[matkatmusic]

put this in a Scripts folder in your repo and add it as a pre-build script in ProJucer:

#!/bin/sh

FILE="../Version.h"

VERSION_NUM=`git log -1 --pretty=oneline --abbrev-commit|sed s/\ .*//`

cat > $FILE <<- EOM
#include "../JuceLibraryCode/JuceHeader.h"

namespace ProjectInfo
{
    const char* const  projectName    = "Your App Name";
    const char* const  versionString  = "1.0.0 ($VERSION_NUM)";
    const int          versionNumber  = 0x10000;
}
EOM

then in ProJucer, set JUCE_DONT_DECLARE_PROJECTINFO as a preprocessor definition.
This will automatically generate a Version.h with your most recent commit number appended to the version number. you could modify it further to read the existing Version.h’s versionNumber line and bump the value by 1…

The only annoying bit I haven’t figured out how to do yet is to automatically include the “Version.h” in main.cpp and also add it to jucer file.

[anthony-nicholls]

@matkatmusic

The only annoying bit I haven’t figured out how to do yet is to automatically include the “Version.h” in main.cpp and also add it to jucer file.

Can you not add this to the AppConfig.h?

EDIT: if you done that you would have to remove the #include "../JuceLibraryCode/JuceHeader.h" line

[anthony-nicholls]

Come to think of it if you do that you could add #define JUCE_DONT_DECLARE_PROJECTINFO 1 to this file too, one less thing to add to the jucer file.

[matkatmusic]

Well, the AppConfig.h gets rewritten every time you save in ProJucer, like if you add new header/cpp files. Maybe your workflow doesn’t involve projucer after the initial project creation, but mine does.

[anthony-nicholls]

if you put "</some/relative/path/>Version.h" inside the BEGIN_USER_CODE_SECTION and END_USER_CODE_SECTION sections it won’t be overwritten, but you will have to commit the file to your repo.

[anthony-nicholls]

I have to apologise I didn’t remember what the resources.rc was for, I realise now it’s for Windows. Inside the rc file you can see at the top that if you define JUCE_USER_DEFINED_RC_FILE to point to some file it will include this instead of defining all the info for you, does this fit your needs?

[yfede]

I’ve always found projucer manages the version just fine including in the plist and the include_juce_audio_plugin_client_AU.r resource file.

In that case, keep in mind that:

Unfortunately, the Rez command (at least in Xcode 8, which I’m using), only reacts to the update of the file it is Rezzing, NOT of those that said file #includes, recursively.
This means that updating “AppConfig.h” with the new version number seems to be not enough, touching the main ‘.r’ file seemed to be the only viable choice

details here: Plugins showing up twice on High Sierra OSX 10.13

[raketa]

@anthony-nicholls: thanks, the plist generation works! Though I don’t see any advantage of having the intermediary projucer between me and the project.
@matkatmusic: What is the ProjectInfo good for?

But my question remains: how can the resources.rc be customized, so that the defines from a header file can be used? Or more precisely how can JUCE_USER_DEFINED_RC_FILE be set:
If defined as preprocessor directive in projucer it will not get forwarded to the resource compiler (VS2015). No other header seems to get included either. Does anybody actually use this? If not how are you setting Windows resources?

[raketa]

Does it work or not?

[adamwilson]

Just to add to the conversation, I have this pre-build script in Xcode which sets the Build number to the number of commits, works very well for my needs:

# Set the build number to the count of Git commits
buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

[anthony-nicholls]

Though I don’t see any advantage of having the intermediary projucer between me and the project.

I don’t think there is anything stopping you from not using the Projucer, if it’s not an advantage for you then go without.

Does it work or not?

I’m not at a Windows machine to test but maybe there is a bug here, possibly because no one is using the feature and a regression has occured at some point? out of interest what Windows resources are you trying to set that the Projucer doesn’t already deal with?

[raketa]

I don’t think there is anything stopping you from not using the Projucer, if it’s not an advantage for you then go without.

Its pretty impractical to keep JUCE up to date without the projucer, but thats a different topic with a lot of ingredients from not providing a referenceable library project to macro orgy.

Is there really nobody who can either confirm or deny that a jucer project can be setup in a way so sets up VS to constructs a Windows version information resource from a header define? Where can JUCE_USER_DEFINED_RC_FILE be set? Or can the resource.rc generation at least be turned off if thats not working?

[anthony-nicholls]

What version information are you missing?

essentially my question boils down to “What is it about the existing resource.rc that’s causing you a problem with versioning?”

For us we set the version in the jucer project file and it just works, we have bump scripts that set the version number - which if you want to make your life even easier the Projucer has command line arguments that let you set or bump the version number.

[raketa]

essentially my question boils down to “What is it about the existing resource.rc that’s causing you a problem with versioning?”

I need to be able to put my version information from a header file in the resource.rc. This is not possible, since the projucer generates the resource.rc and it seems the intended way of setting JUCE_USER_DEFINED_RC_FILE is not working since there is no place to be defined where it reaches the resource compiler of VS.

Do I overlook here something or is there a bug?

[anthony-nicholls]

I need to be able to put my version information from a header file in the resource.rc

Again we use bump scripts so we can update multiple things. If not that, could you consider using the AppConfig.h as the source of your version number rather than the other way around?

This is highly dependant on how you have things setup but if you have some build scripts (I don’t just mean the pre/post build scripts, but the ones that actually trigger the builds) and you regenerate your projects using the Projucer in the build scripts, then you could also handle it there and forget about it when you’re building locally? i.e. your script could read the version from your header file then set the version on the jucer project (using the command line arguments in the Projucer) and resave which will generate a jucer project with the right version just before it builds.

Do I overlook here something or is there a bug?

Sounds likely to be a bug to me. I would say the Projucer probably needs a “Resources Preprocessor Definitions” field in each of the configurations for the relevant exporters, like the “PList Preprocessor Definitions” for Xcode.