The most obvious is that you need to compile the code. There are some hidden gotcha's if you're not using xcode or projectbuilder, however.
In my previous entry I commented on my discovery that you need to add a flag to the compile and link options "-arch i386".
This has allowed the code to happily compile and link, but when the application is executed it starts in the background and refuses to come to the front. No menus, and seemingly unable to accept focus.
Todays discovery has been getting the application to accept focus, this needed further changes to the way that my codeblocks ide is set up, as well as adding a new application to my system.
The dylibbundler is the new application. The main page says that dylibbundler is a small command-line programs that aims to make bundling .dylibs as easy as possible. It automatically determines which dylibs are needed by your program, copies these libraries inside the app bundle, and fixes both them and the executable to be ready for distribution.
But like everything, it wasn't quite as easy as running the command line utility.
Firstly the output directory was changed to myApp.app/Contents/MacOS/myApp
Then I added the following to the Pre/Post build steps:
/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)
/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)
/usr/local/bin/dylibbundler -od -b -x ./SRA.app/Contents/MacOS/$(TARGET_OUTPUT_FILE) -d ./myAPP.app/Contents/libs/
This now gives me a running application that can be brought to the front. Note that the text is wrapping, a copy/paste into codeblocks will help.
Now all I need to do is to get the code to load the text file and display correctly. That might just be a little more difficult than getting codeblocks and OSX to play nicely.
Update: a step I missed out was to set the Output filename for the build targets to point to the modfied file name. For my app I had to set it to bin/osx/Debug/Sim65.app/Contents/MacOS/Sim65.
