Do you really mean scheme? Or do you mean configuration? Schemes were introduced with XCode 4, did you recently updated from Xcode 3.
If i need a release build for testing, i simple build for profiling
Xcode 4? No, I’m running Xcode 7.
Creating a Release build by Profiling makes little sense to me.
My point is that if Projucer is doing all this work for us, why doesn’t it create 2 separate build schemes? Debug & Release? I would do it myself, but the next time I use Projucer, it destroys my work.
I mean schemes were introduced with XCode 4, therefore there was a simple switch between Release and Debug configuration, as far as i remember. Now every scheme contains different build settings for “Run (Debug)”, “Profile” (Release), Archive etc…
You initial post suggest that JUCE 4.2 has changed the way release and debug builds are done, which is not true, and this confuses people like me
My apologies for the confusion. Let me try to explain my position.
When I started my plugin project, JUCE was at 4.0 or 4.1. At some point, I realized that I needed to test how a release build would perform instead of the debug build. This is critical considering the performance difference in debug and release builds. I modified the Xcode project that Projucer created so I could choose to build for debug or release at any time. Also, I was able to go back into Projucer, add new classes, etc, and it didn’t effect my debug and release build schemes. This worked well until JUCE 4.2.
JUCE 4.2 changed the way targets were built (no post build script, etc). After saving my project from Projucer my debug and release build schemes were gone. So, I spent more time reimplementing separate debug and release build schemes. This worked okay until I went back into Projucer and saved the project. My build schemes were destroyed. In my opinion, this is problem from Projucer.
In all honesty, I’m not incredibly versed in the all complexities that go into building multi-platform, multi-format plugins. But that is what JUCE and Projucer are supposed to simplify so I can spend more time coding my actual audio code.
Again, if it’s Projucer’s job to simplify the task of building multi-platform/multi-format audio plugins, then it’s missing that one key feature. Especially considering the the relatively large performance differences between a debug build and a release build.
My suggestion to the JUCE team: Projucer should create Debug and Release builds when saving. Or at the very least, not destroy mine.
Forgive me if I’m missing something incredibly obvious.
We at ROLI simply change the “Build Configuration” to “Release” on the “All” Scheme. Just click on edit scheme… and switch to build configuration to “Release”. The Projucer will not overwrite that. I’m really not sure if it’s worth adding double as many schemes to accommodate a release and debug scheme for every target. It seems to me that changing the build configuration is so much easier.
Please let me know if you know of cases where this does not apply. I’d be happy to take another look.
In Xcode, simply create a Workspace (File > New > Workspace…) and include your Xcode plugin Projects; then create a build scheme that belong to the Workspace and not the Projects, that calls each of the “… (All)” schemes. No more “400 clicks” to build, no more erased build scheme.
I just duplicated the All target and named it All-Release. Then edited the scheme’s build configuration to Release. And that works fine…until I go into Projucer and save the project. My release target is gone.
I think you might be confusing targets and schemes. The Projucer creates the targets but does not create any schemes. Targets have nothing to do with schemes or build configurations. When you open an xcode project created by the Projucer it will contain no schemes. If you open such a project in Xcode GUI (sadly not on the command line), Xcode will auto-create a scheme for each target.
I don’t duplicate the All scheme. I simply switch the scheme’s build configuration from Debug to Release. It’s as easy as switching between schemes.
