Release builds with latest Projucer & Xcode?


#1

Before updating to JUCE 4.2, my Xcode plugin project had both a debug scheme and a release scheme. Now, 4.2 has changed the way builds are done, with separate bits for VST/VST3/AU/All & Shared Code. I’m guessing this is all debug build, and I’m not sure what I need to do to create a release build.

Thanks.


#2

It’s tricky since 4.2 uses symlinks. the files copied by JUCE can be Debug or Release depends on what you’ve built less.


#3

And that’s just it. How can I have a scheme for a Debug build and another for release builds?


#4

Anyone??? Surely someone out there has faced this.


#5

Sorry to keep asking, but seriously, no one out there has an answer to this? I don’t see it documented anywhere that I can find.

Once again, 4.2 changed the way audio plugins are created in Xcode. In Projucer, there’s a Debug and Release exporter. In the created Xcode project, there are the following targets: All, VST, VST3, AU and Shared Code.

If there’s a Debug and Release exporter specified in Projucer, why doesn’t Projucer, create a Debug AND a Release build scheme?

And since it currently doesn’t, could someone from the JUCE team explain the thinking in this new Xcode configuration and how I might achieve, what I would expect, is a very common thing…switching between a Debug and a Release build.

Thank you.


#6

In Xcode you can duplicate a scheme and have one set for Release and another for Debug

Rail


#7

So, I would duplicate each scheme (ALL, AU, VST, Shared Code), and set them to Release configurations?


#8

It sounds like that’s what you want…

Rail


#9

Well, that almost worked. Except that if I go back into Projucer and resave the project and open it back up in Xcode, the Release build schemes have been deleted.

This is crazy.


#10

The way I always switched between debug and release in Xcode, for my whole developer life, was like this: click on the scheme, Edit scheme…, Run, Info Build configuration. It’s exactly four clicks that take me about 5 seconds. This works fine.

It also works for the “Build all” scheme so if you want to build all formats (VST, AAX, …) at once you do not have to switch debug/release for all of their schemes, just the “Build all” one.

If you want your custom scheme to have even less clicks, then yes you have to create it yourself. And yes, any such custom scheme will be overwritten next time you save the project from the Projucer. The reason is that in JUCE 4.2, the Projucer needs to create multiple targets for your audio plug-in, and for every new target Xcode will generate a new scheme.

I believe there is another way of “saving” your custom schemes and re-applying them after you re-saved the project, something involving exporting and importing schemes. Maybe that would be useful. Unfortunately I don’t know how it works, but Fabian does. He will be back on Monday, I’ll ask him to post this here.

Hope this is helpful,
Timur


#11

The horror! :sweat_smile:

I’d be constantly worried of having forgotten the “wrong” setting inside the scheme.
Because of that (and also to avoid the furious clicking for all the schemes) I am one of those “other kind” of developers, that creates a scheme for Debug and another for Release. You are not alone @pizzafilms !

Luckily I prefer IDE configurations files over Projucer, so I don’t have to worry about the IDE project being overwritten (join the dark side :smiling_imp:)


#12

Debug/Release shouldn’t be such horror :wink:

Using a xcodebuild with a proper script is the most fail-safe solution (where you can run additional scripts for checking symbols and other concerns you might have during release build for production…)


#13

It just seems to me that if Projucer makes the effort to ask about Debug and Release build specifications, then why doesn’t it just build both schemes? Especially considering that it destroys all schemes when it saves. And even more importantly, the difference in performance between a Debug build and a Release build is so large, I would think that this would be incredibly important for audio plugin developers.


#14

this needs to be addressed soon

my plug-in features 10 audio devices which are 32 and 64 bit dlls, plus the VST2, VST3, AAX, RTAS, AUs

thats 400 clicks or more for each release…

can we at least have duplicate schemes or make it dont overwrite stuff we create… principal rule of programming is to able to conserve work efficiently… this breaks this rule: duplicate effort wasted every time.


Projucer should create Debug & Release builds
#15

That sounds like a good idea to start…Projucer should not delete other schemes.

But I still think it should create both Debug and Release schemes.


#16

We’ve seen your requests and we are looking on a way to create Debug and Release schemes and on a way to retain workspace files.


#17

Thank you.


#18

I’m little bit unsure now, the command

xcodebuild -configuration Release

should create the Release-build always?


#19

Im still confused about this topic

Before updating to JUCE 4.2, my Xcode plugin project had both a debug scheme and a release scheme. Now, 4.2 has changed the way builds are done, with separate bits for VST/VST3/AU/All & Shared Code. I’m guessing this is all debug build, and I’m not sure what I need to do to create a release build.

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


#20

That’s what I’ve been doing as well. I do still think it feels a bit strange though, having to build something for profiling (which then causes a release version to be built) whereas I won’t be profiling at all. Side-effects thing and all…