Projucer vs reproducible build

I’m trying to git-bisect a bug in my project, so I’m building an old commit. I have JUCE as a submodule and I have a script that builds the projucer and opens my project in it. But the old projucer shows this and doesn’t agree to work:

This version of the Projucer is out-of-date!

True, but the point of my reproducible build was to use the old sources and versions which worked in the past.

Always make sure that you’re running the very latest version,

That goes counter to doing git-bisect

preferably compiled directly from the JUCE repository that you’re working with!

I am compiling directly from the JUCE repo I’m working with!!

Did you make sure that the Global Paths settings “Path to JUCE” and “JUCE Modules” are pointing to your JUCE submodule and not something else?

Are you using user modules in your project?

Indeed there were global paths settings. On that note could we please remove those? From what I see they only cause trouble.

1 Like

I’m assuming the purpose of the Global settings are a leg-up to people just starting out - e.g. people who have a single install of JUCE on their machine and are just building learning projects rather than things that need to be supported long term.

Once you get to using JUCE as a sub-module they can interfere as they are outside version control… and if you’re using dedicated build machine(s) not being able to version control a fully reproducible build leads to manual steps which is kinda against the point (though having to plug an iLok in for wraptool is another pain here)

Perhaps a solution where the ‘global paths’ act as the defaults for new projects would be a suitable solution for both usecases?

2 Likes