# Add command line option to override global projucer settings **URL:** \ **Category:** Feature Requests\ **Created:** [November 12, 2019, 9:41am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112 "2019-11-12T09:41:52Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [November 12, 2019, 9:41am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/1 "2019-11-12T09:41:52Z")
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. ```auto Projucer --settings myCIprojucer.settings --resave myProject.jucer Projucer --ignore-global-settings --resave myProject.jucer ``` The second one would be synonymous of supplying an empty file. And you don’t need to delete the global settings file at each CI run, like suggested in another thread… From this previous thread [Unable to Build PIPs on CI (Travis/Azure etc.)](https://forum.juce.com/t/unable-to-build-pips-on-ci-travis-azure-etc/31122/4) ---
**Author:** ![jimc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jimc/32/16067_2.png) [@jimc](https://forum.juce.com/u/jimc)\ **Post date:** [November 12, 2019, 9:47am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/2 "2019-11-12T09:47:52Z")
Can it also be a per-project setting 🙂 ---
**Author:** ![dave96](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/dave96/32/8487_2.png) [@dave96](https://forum.juce.com/u/dave96)\ **Post date:** [November 12, 2019, 10:27am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/3 "2019-11-12T10:27:46Z")
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. ---
**Author:** ![dave96](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/dave96/32/8487_2.png) [@dave96](https://forum.juce.com/u/dave96)\ **Post date:** [November 12, 2019, 10:28am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/4 "2019-11-12T10:28:15Z")
But yes, also having a per-project setting to completely disable the global lookup would get my vote. ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [November 12, 2019, 11:04am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/5 "2019-11-12T11:04:02Z")
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 ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [February 6, 2020, 12:47pm UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/6 "2020-02-06T12:47:56Z")
Bumping this… Would be great to have a solution, or we have to move to FRUT 😉 ---
**Author:** ![RolandMR](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rolandmr/32/641_2.png) [@RolandMR](https://forum.juce.com/u/RolandMR)\ **Post date:** [February 6, 2020, 1:32pm UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/7 "2020-02-06T13:32:29Z")
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) ---
**Author:** ![lucianthorr](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/lucianthorr/32/6706_2.png) [@lucianthorr](https://forum.juce.com/u/lucianthorr)\ **Post date:** [May 22, 2023, 5:29pm UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/8 "2023-05-22T17:29:39Z")
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. ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [May 23, 2023, 8:54am UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/9 "2023-05-23T08:54:04Z")
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. ---
**Author:** ![lucianthorr](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/lucianthorr/32/6706_2.png) [@lucianthorr](https://forum.juce.com/u/lucianthorr)\ **Post date:** [May 23, 2023, 2:05pm UTC](https://forum.juce.com/t/add-command-line-option-to-override-global-projucer-settings/36112/10 "2023-05-23T14:05:21Z")
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.