I’m in the process of porting my project to OSX which for me is a daunting task given the little experience I have on this platform or with Xcode. My first task is to create a standalone from the demo VST plugin, and I’ve already hit a snag. Here’s what I did:
Build the demo VST/AU plugin to make sure all the paths were ok, it built fine.
Went to Project->Edit Project Settings->Configuration, duplicated my ‘Debug’ config and renamed it ‘Debug-Standalone’
In my ‘Debug-Standalone’ settings I went to user-defined settings and added JucePlugin_Build_Standalone 1
Also in ‘Debug-Standalone’ settings I set ‘Executable Extension’ to .app
I made sure JucePlugin_Build_Standalone is set to 1 in my jucePluginCharacteristics.h
It get’s through the compilation and linking fine but my application juce won’t start. I’m pretty sure it’s not building a proper standalone(based largely on the fact that most of the steps outlined above are rooted in complete guess work!). How do I tell Xcode not to build a library but a standalone as one does in MSVC? I’m probably missing other things too so if anyone could fill in the gaps above I’d really appreciate it.
The xcode settings are a bit of a nightmare - I’d have suggested it’s better to start with a project that’s an app and add your code to it rather than trying to turn a library into an app. I’m sure it’s possible by changing the right settings though.
Sounds like fun, especially when I don’t know what I’m doing with xcode to begin with! Hopefully Atom will chip in here with some advice. He assured me it’s ‘relatively’ straightforward in an earlier post.
I did a new build system for myself, i did two seperate projects for standalone and VST version (i build from the command line anyway so i don’t care how many of those projects i have). The new projects are here http://ctrlr.googlecode.com/svn/trunk/Controllers/Ion/Build/Mac/
why new ? cause i added the JUCE source to them (it’s not linked anymore the mm amalgamated file is in the project) and it deals with the obj-c object naming issues.
I took my code from the JUCE Demo or JUCER projects (don’t remember witch one now), but as i can remember creating a new app did the trick too. What happens when you try to debug your app, does the debugger start ? perhaps it goes into the
(gdb) <waiting for input
mode, this means there is something wrong with your app. Give us more details if you can about how is your app reacting. You can always check what is your file using the “file” command in the terminal
file MyDemoPlugin.app/Contents/MacOS
this will tell you if your app is the right type architecture and other info.
The debugger doesn’t start at all and I can’t hit ‘Build and Go’ either? I only get build? Sounds like the easiest thing to do is to have two separate projects sharing the same source code. That will work fine for me I suspect. When I run file from the command line i get:
JuceDemoPlugin.app/Contents/MacOS/JuceDemoPlugin: Mach-O bundle i386
Is that how it should be? It’s so odd that ‘Build and Go’ is disabled, surely I should be able to launch my app from within xcode, this must be why my debugger isn’t running either, i.e., it can’t launch the application.
if the debug option is not active this means there is no binary target defined that can be debugged directly in xcode, so either you have no target or your target is a library/bundle/component.
You were right. In my project settings Mach-o type was set to bundle rather than executable. Now it works fine. Turns out it’s not that tricky at all. One last question if you don’t mind, usually when building apps on OSX does one generally just create a binary or does one have to create folder with a .app extension that contains all your files? ~This is my first time writing anything for OSX, be patient with me!
it’s how OSX ui treats apps, all the info resources icons for the app are in the .app folder, and xcode creates one for you. So yes a standard binary package like ELF on linux is a directory on OSX, though directories are files so it’s really the same thing (i have to love unix)
(i have to love unix)