Could there be two options added to the projucer commandline to override the global settings file with a separate one or by using no global settings at all?
This would be very useful for self contained projects, build scripts etc. especially on continuous integrations.
I don’t really understand why it needs to be used in this way at all?
I’ve spent so much time trying to get things to build on CI and fighting with the global settings.
I get that for some users having a single JUCE dir and then creating lots of projects referencing those modules may be quicker and use less disk space, but can’t the setting just be copied in to the individual .jucer project upon creation? If you move JUCE, then you’ll just have to update the project.
I think we have similar workflows, judging from how pluginval is setup…
I share projects via github, so having set it to use global paths allows maximum portability.
Now I have also a master repository for CI, where juce is included as git submodule and built each time, so I need to override the global path to use the included modules.
I am aware of the Projucer --set-global-search-path os identifier_to_set new_path, but that changes the settings?
IMHO the CI build should be self contained and not accessing any settings outside the build container (considering parallel builds).
Especially since implementing that feature is straight forward, just set the path for the ApplicationProperties to the one given in the command line.
It also allows to check-in the “global settings” into your build container
It would also be nice to have a command line option to disable plugin copy step or at least make the plugin copy step smarter so that it doesn’t fail the build if the plugin dir doesn’t exist.
I’m not sure how to use the command line to create folders and make them writable to everybody. So I’m just using sed to disable plugin copy step. (This is on windows)
In case it’s helpful for anyone, I think you can actually set a local JUCE path inside the project’s XML by setting the juceFolder attribute inside the JUCERPROJECT block.
If you do a search in the JUCE GitHub for juceFolder, you’ll see that it’s set in a few example projects. It seems to be working for me and it definitely saves me from the race condition where multiple CI jobs are trying to set the global JUCE path at the same time before exporting their projects.
Yes, the juce folder ca be set in the jucer project. However that doesn’t solve the issue, to be able to change settings from the global projucer settings.
Anyway, I don’t hold my breath that any work is done on Projucer. It’s easier using CMake, even though it is another thing to learn.
Yeah, totally not a solution to the original request but a possible solution to anyone who stumbled onto this thread with the same objective as I did a few days ago.
A lot of the posters above seemed to be asking in reference to CI, which was the problem I was solving for also, but using global settings in CI is not a good idea. If you’ve got multiple CI jobs trying to set a global .settings file at the same time, you’re going to run into race conditions. You could also accidentally build project X with the JUCE folder from project Y.
I think it’s a better practice to keep all your project’s settings local to the project whether it’s with the Projucer or CMake.
