moving Mac OS X game to another OS X machine....

[WhatMeWorry]

Ok, this is sorta embarrassing (hey, there is an "ass" in embarrassing) but
I have a little working game in Xcode, OS X TIger etc. and I moved it to
another OS X machine via CD and tennis shoes.

I start up the application (on new machine) and it is aborting before anything
happens. I've got a log file which the application should create and write to.
This log file never gets created much less written to. All file paths are relative
to the game and it's folder.

I checked permissions and the application and data files seem to be all "read and
write" The Finder doesn't seem to list "execute".

It there any obvious thing I'm not addressing here? Maybe "users" or something?
I grasping at straws here.

[OneSadCookie]

turn off zerolink

[kelvin]

For future reference, you can open Applications>Utilities>Console.app to see that, indeed, the problem was Zero link. The easiest way to prep your app for deployment is to change build style to ...deployment... and do a clean and rebuild. Saves having to toggle specific things on/off. Though not quite as helpful if you're still trying to debug as I think that setting will strip those symbols.

[unknown]

I cd into the directory of the .xcode file and 'xcodebuild install'. That makes an alias to a deployment copy.
I with it was simpler, I cant find deployment.

[Malarkey]

For future reference, you can open Applications>Utilities>Console.app to see that, indeed, the problem was Zero link. The easiest way to prep your app for deployment is to change build style to ...deployment... and do a clean and rebuild. Saves having to toggle specific things on/off. Though not quite as helpful if you're still trying to debug as I think that setting will strip those symbols.

For XCode 2.0, they keep the executables for the different build styles in separate folders now so you don't have to do the whole clean and rebuild process (and thank god for that too -- yeesh!)

Plus they're finally calling them Release and Debug (unless you upgraded an old project).

[WhatMeWorry]

Thanks for all the suggestions. I'll incorporate all this new knowledge going forward.
But it turns out that it was a path problem all along. I thought the following code
would retrieve a dynamic path at runtime, but it appears to be hard coded to the path where
the app was originally built. Can anyone recommend a system call or calls that would
return the path of the executable when started up. That is, no matter where I put
an executable on a new system, it would return this new path. I'll be reading ADC
docs in the meantime. But this is rarely successful with me :)


CFURLRef appURL = CFBundleCopyBundleURL(CFBundleGetMainBundle());

// Get the directory containing the app
CFURLRef parentURL = CFURLCreateCopyDeletingLastPathComponent(kCFAlloca torDefault, appURL);

// Convert to native file system representation
UInt8 path[PATH_MAX];
CFURLGetFileSystemRepresentation(parentURL, TRUE, path, PATH_MAX);


string pathString = (char *) path;

[akb825]

Why do you need the path to the executable? The your bundle's location is already the current directory. So if you have a Textures folder in the same folder as the bundle, you can access a picture in it with "Textures/picture.tga" If you are accessing a picture in a Textures folder inside the bundle, you can access it with "AppName.app/Contents/Resources/Textures/picture.tga" Adjust as needed.

[OneSadCookie]

Why do you need the path to the executable? The your bundle's location is already the current directory. So if you have a Textures folder in the same folder as the bundle, you can access a picture in it with "Textures/picture.tga" If you are accessing a picture in a Textures folder inside the bundle, you can access it with "AppName.app/Contents/Resources/Textures/picture.tga" Adjust as needed.

Nonsense.

This will be true if you run your app from within Xcode, and if you are using SDL. If you're using GLUT then the current working directory will be your bundle's Resources folder. Otherwise, you can't predict the CWD, though the Finder likes to use /.

You should also never attempt to find your bundle by name (AppName.app/Contents/Resources), because the user can rename your application.

WhatMeWorry's approach is correct.

[akb825]

Hm, well I'm working on a cocoa program right now (without using SDL or GLUT), and it worked like that. I haven't tried moving it etc, but thanks for steering me in the right direction.

Edit: sure enough, I moved the app and it didn't work.

[unknown]

Its ok to do
texturesPath = [[NSBundle mainBundle] bundlePath];
texturesPath = [scriptPath stringByDeletingLastPathComponent];
textures = [textures stringByAppendingString:@"/textures/"];
In a cocoa program isnt it?

ed:it: if your application is in the same folder as the textures folder

[WhatMeWorry]

This is real kludgy but it gets the job done and I'm not ready to become an expert
on bundles just yet. The problem for me at least was FBundleGetMainBundle() was always
returning a path to the bundle in Xcode even when I moved the application to say my
desktop. (Maybe I need to explicitly make a bundle (package) in Xcode?) Plus, the path
was not to the application directly, but to the bundle (several directories underneath where the app is (was).

At least the below gives me a path to the application itself. But it is kludgy in that
I have to go into the Info.plist file in the bundle and hard code the CFBundleIdentifier in my app.
So after I move the exectable out Xcode onto my desktop, I get
path = /Users/kyle/Desktop


// from Info.plist in Xcode for the project
myBundle = CFBundleGetBundleWithIdentifier( CFSTR("com.apple.myCarbonApp" ) );
CFURLRef appURL = CFBundleCopyBundleURL(myBundle);
CFURLRef parentURL = CFURLCreateCopyDeletingLastPathComponent(kCFAlloca torDefault, appURL);
UInt8 path[PATH_MAX];
CFURLGetFileSystemRepresentation(parentURL, TRUE, path, PATH_MAX);



Edit: The above works when I move the app around on my machine. But it
is failing when I move the exec to another machine :mad:

Edit:Edit: Ok, looks like my previous Edit needs to be clarified. The new
machine is complaining in the console about "libary no loaded: sw/lib/libpng12.0.dylib
So this is another issue probably relating to the PNG dynamic library. So hopefully,
the paths are correct on the new machine.

[PowerMacX]

The sw/ directory is where Fink installs stuff, so you shouldn't expect end users to have any libraries at that path.

[WhatMeWorry]

Right, so now I presume I need to figure out how to bundle that library into
my application bundle. This should only take a few hours, days or WEEKS OF HAIR PULLING :)

[AnotherJake]

You just need to statically link libpng.a into your app instead of dynamically linking against the .dylib, so that it's compiled along with your source, instead of needing to be loaded from some other location upon launch. I can't guarantee there won't be any pulling of hair or gnashing of teeth though. ;) GCC seems to *love* linking to dylibs regardless of what you want. We seriously need a FAQ on this subject. I'll just be short and say that the trick is to rename the libpng.whatever.dylib file to something else so that Xcode (GCC) can't see it -like XcodeCanSuckAtTimes.libpng.3.dylib. And make sure in your project info that your "Other Linker Flags" has -lpng and -lz included as well.

[edit] You'll probably wanna drag the libpng.a library into your Xcode project too. I don't remember why but I think zero link will throw a fit without it.

[Steven]

Watch out for licensing though! If you statically link, it could bring up issues... (I believe the GPL has problems with this on non-GPL projects)

[AnotherJake]

Yeah, you most definitely need to keep a sharp eye on the licensing issues when statically linking libraries. libpng doesn't present any legal issues as far as I know though.