Can't export JUCE examples to Xcode on Monterey

[vascofsantos]

Hi!

I’m running macOS Monterey 12.0.1 (Intel) and Projucer on JUCE 6.1.2 and I can’t seem to be able to export the built-in examples to Xcode 13.1.

I open the examples and then click on the export button and nothing happens. Then, the Projucer UI becomes unusable.

It seems to work fine when creating and exporting new projects.

Does this happen to more people or could there be something wrong with my system?

[modosc]

i’m seeing this too on 12.0.1 (arm64). i tried with the pre-built projucer from the website as well as my built version and they both hang on saving / exporting a project. going to open up a debugger to see if i can find anything more

[modosc]

the cli version still works so i wonder if it’s something ui/thread related?

$ /Applications/Projucer.app/Contents/MacOS/Projucer --resave InstrumentDesigner.jucer
Re-saving file: /Users/jon/git/InstrumentDesigner/InstrumentDesigner.jucer
Finished saving: Xcode (macOS)
Finished saving: Xcode (iOS)

[reuk]

I investigated this yesterday and put together a potential fix. Hopefully this will make it to develop early next week.

[reuk]

The fix is now out on develop:

Projucer: Fix temporary project save/open in Xcode on Monterey

Please try rebuilding the Projucer and make sure that the issue is fixed for you too. As always, let us know if you run into any further problems.

[modosc]

thanks @reuk - saving still takes longer than pre-xcode 13.1 seemed to (~5-10s) but it’s working now.

[modosc]

hi @reuk - unfortunately this fix isn’t really working. i just rebuild projucer from develop and made a video of exporting an example project and opening it in xcode. it takes ~80s to finish:

monosnap.com

this is on macos 12.0.1 on arm64.

[reuk]

Thanks, there were a few issues in the Projucer’s saving procedure that made it slow and unreliable.

The problems I was seeing included:

• Sometimes the project would be saved twice in a row before opening in Xcode (the problem you were seeing).
• Sometimes the project would save once, but then fail to open the exported project in Xcode.
• Occasionally, an assertion would fire in the destructor of the Thread running the background module detection.

I’ve made some improvements here:

Projucer: Ensure that saving always continues after moving a project

Projucer: Require a resave whenever any ValueTree property changes

Projucer: Only resave project if necessary

Projucer: Use std::async instead of ThreadPool in module scanner

Hopefully the save/export flow should be a bit more robust now. Please try updating and let us know if you’re still encountering problems.

On a tangentially related note, I’ve also made a tiny tweak to the mac ComponentPeer that allows the Projucer to display the document’s save state inside the close button, as is the norm for macOS applications:

ComponentPeer: Add facility for displaying document save state in the titlebar

Projucer: Show document save state in the titlebar

[modosc]

thanks @reuk.

one other issue i’ve only seen on monterey - i randomly get the “At least one of your JUCE module paths is invalid” message when saving, both in Projucer.app (via a little popup window) and on the cli (from /Applications/Projucer.app/Contents/MacOS/Projucer --resave) . it doesn’t happen 100% of the time and when it does i can’t reproduce it. i’ve added a projucer patch locally but i think it’d be useful to print the name of the module that projucer is unhappy with:

diff --git a/extras/Projucer/Source/ProjectSaving/jucer_ProjectSaver.cpp b/extras/Projucer/Source/ProjectSaving/jucer_ProjectSaver.cpp
index fcfa71b00..d33a06ac4 100644
--- a/extras/Projucer/Source/ProjectSaving/jucer_ProjectSaver.cpp
+++ b/extras/Projucer/Source/ProjectSaving/jucer_ProjectSaver.cpp
@@ -257,7 +257,7 @@ OwnedArray<LibraryModule> ProjectSaver::getModules()
     {
         if (! module->isValid())
         {
-            addError (String ("At least one of your JUCE module paths is invalid!\n")
+            addError (String ("At least one of your JUCE module paths (" + String(module->getName()) + ") is invalid!\n")^M
                 + (isCommandLine ? "Please ensure each module path points to the correct JUCE modules folder."
                                  : "Please go to the Modules settings page and ensure each path points to the correct JUCE modules folder."));

of course this hasn’t happened yet since i added the logging. i’m wondering if anyone else is seeing this as well or if it’s unique to my setup.

[modosc]

actually i’m seeing the issue again

@reuk please let me know if i can assist in debugging

[reuk]

@modosc

actually i’m seeing the issue again

Which issue are you referring to? The initial resaving issue, or the module paths issue?

[reuk]

I just tried to reproduce the module paths issue, and wasn’t able to (I ran --resave from the commandline 100 times in a row).

It might be helpful to add module->getFolder() to your logging, so that you can see where Projucer is looking for the module. To debug further, it would be useful to know the location where the Projucer expects to find the module, your ‘global paths’ settings, and the module location settings specified in the .jucer file.

• If the Projucer is looking for the module in the global path rather than a specified path (or vice versa) then that might indicate an issue in the path resolution logic.
• If it’s looking in the right place but incorrectly reporting that the module doesn’t exist, then that might indicate an issue in the way that the module’s presence is detected.

[modosc]

hah sorry, i meant the slow exporter bug. i’m up to date on develop and i’ve had a save running in the background for >1m now.

specifically i took a known good .jucer file, add a trailing space to the Extra Compiler Flags value in the Xcode (macOS) exporter, and saved via ctrl+s. i do have xcode open right now if that matters.

i’ll open a separate thread for the module issue if i can repro it.

[reuk]

Just so that I know what I’m looking for, is the issue just that the export is slow? It’s not saving multiple times, or failing to open Xcode?

Is it slow in both commandline and GUI modes?

[modosc]

it’s slow saving from the gui. the issue is identical to the video i posted originally.

i haven’t seen any issues from the cli but i only make those calls from ci, so if they did take a few minutes i probably wouldn’t notice.

i’m going to run in the debugger to see if i can get anything more useful.

i’ll also add logging to my ci setup to see how long it takes there.

[modosc]

i ran in the profiler. it’s been 3 minutes and the dialog is still going:

[modosc]

the cli seems fine, i ran this ~10 times and no hangs:

$ time /Applications/Projucer.app/Contents/MacOS/Projucer --resave InstrumentDesigner.jucer
Re-saving file: /Users/jon/git/InstrumentDesigner/InstrumentDesigner.jucer
Finished saving: Xcode (macOS)
Finished saving: Xcode (iOS)

real	0m1.590s
user	0m0.988s
sys	0m0.247s

[reuk]

When saving from the commandline, the projects are saved on the main thread, but when using the GUI the projects are saved on a background thread. I suspect that the background thread is of lower priority, leading to the slowdown.

There have been a few thread-priority related defects recently, so perhaps the code that sets the thread priority needs a bit of an overhaul.

[seanwayland]

Thanks I managed to pull from the develop branch and build a demo project on Monterey 12.0.1 on a macbook with an M1 pro chip just now. A couple of my old plugs seemed to have stopped working. OSX says they are 32 bit which surprised me I didnt think that was the case … Anyhow I am going to try and rebuild them on this thing …

[reuk]

This thread is specifically for Projucer export issues, but your problem seems to relate to architecture/compatibility issues. Please would you start a new thread for that topic, or move to an existing relevant thread? Thanks!