Unable to Build PIPs on CI (Travis/Azure etc.)

The Projucer
#1

I think there’s something a bit wrong with the logic to determine if the command line JUCE module path is being used to determine the paths. In PIPGenerator::setProjectSettings there’s this:

    if (useLocalCopy && isJUCEExample (pipFile))
    {
        auto juceDir = getAppSettings().getStoredPath (Ids::jucePath, TargetOS::getThisOS()).get().toString();

        if (isValidJUCEExamplesDirectory (File (juceDir).getChildFile ("examples")))
        {
             defines += ((defines.isEmpty() ? "" : " ") + String ("PIP_JUCE_EXAMPLES_DIRECTORY=")
                         + Base64::toBase64 (File (juceDir).getChildFile ("examples").getFullPathName()));
        }
        else
        {
            return Result::fail (String ("Invalid JUCE path. Set path to JUCE via ") +
                                 (TargetOS::getThisOS() == TargetOS::osx ? "\"Projucer->Global Paths...\""
                                                                         : "\"File->Global Paths...\"")
                                 + " menu item.");
        }
    }

Which on CI always fails because the Ids::jucePath has never been set. Should it not try to use juceModulesPath as a fallback?

Remember, I can’t set the global modules path because I have Azure instances running on local machines. If one job sets the global path and then deletes the folder whist another job is trying to access it this will break.

Cheers!

#2

This should fix things:

1 Like
#3

Yep, that seems to work, thanks!

#4

While this fixes one particular case, would you consider adding a flag like

Projucer --settings MyProjucerSettings.settings
Projucer --ignore-global-settings

which allows to create build scripts on CI, that are independent from the world outside.

And you don’t need to delete the global settings file at each CI run, like suggested in another thread…

Projucer project upgrade process
Add command line option to override global projucer settings
#5

Where would the settings file preference be stored though? The command-line calls spin up isolated instances of the Projucer so the setting would need to persist after calling --settings or --ignore-global-settings.

#6

The idea was to be able to specify an alternative location for the global settings file, that could be inside the mono-repo for the CI.
The most convenient way to create it would be, to copy the file from ~/Application Support/Projucer/Projucer.settings into the repo and use it like this:

Projucer --settings ${repo}/Projucer.settings --resave MyProject.jucer

After that you can set your settings in Projucer to whatever you want, it wouldn’t affect the CI builds.
And in case, you have everything in your jucer file and you want to work with default values, you would use the

Projucer --ignore-global-settings --resave MyProject.jucer

which does the same like erasing the settings file at the beginning of your build, except that you still have your original settings for all other uses.

#7

@ed95 It’s not my thread, but I would like to make this a feature request…

#8

Which I did now here: