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!