Xcode 10 vs JUCE

Xcode 10, by default, doesn’t properly rebuild the JUCE sources. This is probably due to it being confused by .cpp files being #included. This causes bugs and headaches (“aaahh why didn’t it show my debug print!?!”).

Things however still work fine if enabling the “Legacy Build System”.

I suggest that the Projucer should save the project with this setting, and this commit (from SR’s juce5 branch) makes it do that. If and when the problem is fixed in the future via Apple changing their build system or JUCE adapting itself to it (I suspect the legacy system will be dropped at some point), this change should be removed.

Cheers, Yair

4 Likes

I remain very conflicted over XCode 10. I like to stay current with my build chain, but am just not ready to tell my customers I’m not supporting them if they want to use 32-bit systems that they have confidence in simply because of an arbitrary decision by Apple. Further having to depend on a legacy build system that Apple will most likely yank from me at some unpredictable point in time gives me the heebie-jeebies.

1 Like

For building macOS plug-ins, Xcode 9 is still the way to go.
This commit isn’t breaking Xcode 9 export (tested), as SR still uses Xcode 9 for building.

That’s right.
But if you consider any consequences all are better than current situation -

  • Apple fix bugs in the new Build System - this commit can be reverted.
  • Apple ditches/break Legacy Build System - JUCE build will fail, this will be reverted and will get back to current state or improved by changing JUCE code to overcome Xcode issues.
1 Like

i don’t have this problem with ios and mac os applications built using juce and xcode 10, fwiw.

Do you update JUCE a lot? When you edit some juce_something.cpp, for example to add a simple syntax error! line, does Xcode properly recompile it and report the error?

5 Likes