Projucer --resave is async, how to wait for its output?


I am refactoring parts of my CI/CD and I discovered that I cannot call the compiler right after the Projucer, as it hasn’t finished writing the project files. I can also see that the Projucer (still) writes to standard output after my compiler call.

Previously I did this with separate triggers with apparently enough time between the Projucer and the compiler calls.

Is there an option or a trick to make the Projucer save these files before returning control to the calling script, or to make that script wait until the Projucer has completed?

I use portable Powershell 7.2 for scripting.

[Edit] I can make it work by running

Start-Sleep -Seconds 3

after invoking the Projucer, but I think there should be a more reliable solution.



check is the Projucer still running via process list?

Yes, of course it is still running while the compiler is also started

The async saving is done in the Projucer’s method ProjectContentComponent::saveProjectAsync() (line 401 in Juce master 7.0.5).

I will have to go for the sleep() workaround - still hoping that someone has a much smarter approach, I’m not good at command line scripting.

I mean, if You want to wait until Projucer exit, then do while loop with checking for it’s process, then when no process is found - step to compile.

1 Like

I get it, thanks!

Like I said, I’m not good at command line scripting :grimacing:

If you’re using powershell then use Start-Process with the Wait command, e.g.:

Start-Process -FilePath pathto\Projucer.exe -Wait -ArgumentList "--trim-whitespace", source_folder



I am now using:

Get-Process Projucer -ErrorAction SilentlyContinue | Stop-Process -PassThru -Force

. $Projucer --resave $ProjucerFile

Get-Process Projucer -ErrorAction SilentlyContinue | Wait-Process

With $Projucer having a relative path into my Juce submodule

(the first line is for the situation when I run this locally and there is still a Projucer GUI session open)

This seems an odd issue. In my experience the resave command from the command line is synchronous. But I’m still on Juce 6 for various reasons. Still, in the latest juce_CommandLine.cpp on line 114 there’s:

if (justSaveResources)
    onCompletion (project->saveResourcesOnly());
    project->saveProject (Async::no, nullptr, onCompletion);

indicating at least the intention to save synchronous from the command line. Which makes a lot of sense. Asynchronous saving from the command-line feels like a bug of sorts.

1 Like

I also dived into the source first and it really saves asynchronously (master 7.0.5 here).
I agree this is not what you expect from a simple command line use case.

Yes, it does call this code, but then also the async version :wink: See below

Just an assumption, Is a secondary projucer running in the background? (And the command-line projucer delegates it to the GUI app, via anotherInstanceStarted()?

Just an assumption, Is a secondary projucer running in the background? (And the command-line projucer delegates it to the GUI app, via anotherInstanceStarted()?

No, as you can see up in my lines, I explicitly added a Stop-Process to avoid that option.

I think there may be a bug here, as the Sync save option - mentioned by @pflugshaupt - is executed first and then the Async save is called.

Tagging @reuk to notify someone from the Juce team.

This is called first, in jucer_CommandLine:

if (justSaveResources)
    onCompletion (project->saveResourcesOnly());
    std::cout << "Saving SYNC: ";
    project->saveProject (Async::no, nullptr, onCompletion);

and then:
(2x cout is from me)

void ProjectSaver::save (Async async, ProjectExporter* exporterToSave, std::function<void (Result)> onCompletion)
    std::cout << "Saving A-SYNC: ";
    if (async == Async::yes)
        saveProjectAsync (exporterToSave, std::move (onCompletion));
        onCompletion (saveProject (exporterToSave));

Giving this output:

Saving SYNC: Saving A-SYNC: Finished saving: Visual Studio 2022 - Builds-<snip>
Finished saving: Xcode (macOS) - Builds-<snip>/MacOS-Intel
Finished saving: Xcode (macOS) - Builds-<snip>/MacOS-Silicon

The fix as suggested and discussed above works well for my pipelines, so I can continue with my work.

Thanks all