I have a single OSX target in Introjucer, with two configurations, one for 32-bit and one for x64. No problems here.
The generated XCode project shows the two configurations indeed. So far, nice.
But then there is just one scheme in XCode and it builds the 32bit configuration only.
So, what is the best practice for building the x64 configuration as well?
So far I duplicated the default scheme to an x64 version and edited the copy to use the x64 configurations for RUN/TEST/PROFILE/ANALYZE/ARCHIVE.
Is this what I’m supposed to do? Or should I add another target in XCode instead?
Thanks for any insight on this. Trying to get my head wrapped around this Scheme thing in XCode 4 - rather confusing stuff for an old VisualStudio guy like me :?
The first, and most pertinent question is do you actually want separate builds?
If you’re new to Macs you might not be familiar with so-called fat binaries. In short, for applications the standard approach is to tell your release and debug schemas about all supported architectures, and XCode will compile and link a single executable containing all of them. You can set this up from the introjucer by simply selecting the 32/64 bit option.
If you do need different targets then I’m not sure what the best way to approach that would be. Duplicating the schema will work, but you’ll lose your changes every time you change the introjucer settings. Since you’re only going to need to build for the non-native architecture for release builds which should be infrequent, it might just be easiest to compile, open up introjucer and switch the release architecture, save and open XCode, compile again.
yes that’s an excellent point Valley - could be a very neat way out of this
the only thing I’m not sure of is whether fat 32/64 binaries have any drawbacks in practice?
More specifically I’m building AU / VST plugins. Are these typically deployed like fat binaries too? Or do people need more control?
For instance there is stuff to consider like 32 vs 64-bit hosts, 32->64 bit plugin bridges, etc that might require more control over which plugin version is deployed.
I don’t do audio plugins, so I don’t know for sure, but I can’t think of any good reason why UB wouldn’t be supported (especially for AUs). If the host is using the standard system calls to open the library, OSX takes care of pulling the appropriate architecture from the fat binary.
Re plugin bridges, I guess that depends on the host. A 32bit host wont run 64bit plugs so that’ll always use the appropriate arch. A 64 bit host could do both, but I’d assume the first try would be a naive attempt to open the library, followed by an attempt to open it through a bridge if things didn’t work out. Assuming things with hosts though is not a great idea.
[quote=“mucoder”]yes that’s an excellent point Valley - could be a very neat way out of this
the only thing I’m not sure of is whether fat 32/64 binaries have any drawbacks in practice?
More specifically I’m building AU / VST plugins. Are these typically deployed like fat binaries too? Or do people need more control?
For instance there is stuff to consider like 32 vs 64-bit hosts, 32->64 bit plugin bridges, etc that might require more control over which plugin version is deployed.[/quote]
In my experience, hosts on Mac support fat binary plug-ins, and they will bridge only if the plug-in itself does not contain their native architecture.
