Mac OSX - HELP! (fwd)

Guys?

Forwarded message: -------------------

I finally got an iBook and I want to start porting my games
to Mac. They use SDL and C++, and some custom Python build
scripts to make Linux (natively) and Win32 (cross-compiler)
binaries. I’d like to port this environment to the iBook.

I downloaded and installed XCode, so I have gcc. I also
downloaded Fink and I’m installing the SDL libs right now.

The big question is, what next? I hope to run my Python scripts
(which basically call g++) and be able to build Mac binaries. I
want them to run in OS X and up.

I have no idea about running Python/SDL binaries on Mac, but I’d
recommend you contact the PyGame (http://pygame.org/) folks, who have
obviously done some work on this. They also provide docs.

Some additional questions… sorry if you consider them off topic
but I couldn’t find a good “tutorial” on this.

How do I distribute an app built this way? In Win32 and Linux I
distribute the executable, the SDL shared libs, and some resource
files. In Mac I find I can install an “application” which seems
to be a whole directory tree. How are these things built? It’s just
a directory whose name ends in “.app”?

Essentially, yes, but with a special structure. And it’s important that
you care about the lib dependencies, too. For this reason, I always
static link my release binaries, that way, there is no hassle with
installing SDL libs. Your users will hate you if you force stuff like
that on them :-).

Some information about this topic can be round in README.MacOSX, you
should consult that first. Then, as am example, this is what
ScummVM.app looks like:

$ tree ScummVM.app/
ScummVM.app/
-- Contents |-- Info.plist |-- MacOS |– scummvm
|-- PkgInfo
-- Resources– scummvm.icns

We create it with a simple hand written build rule. Look at this:
<http://cvs.sourceforge.net/viewcvs.py/checkout/scummvm/scummvm/
Makefile?content-type=text%2Fplain&rev=1.65>
So no black magic…

The “Info.plist” file is an almost static XML file. In the case of SDL,
it is indeed fully static and in our CVS:
<http://cvs.sourceforge.net/viewcvs.py/checkout/scummvm/scummvm/
Info.plist?content-type=text%2Fplain&rev=1.13.2.5>
For exult, it is instead created from an “Info.plist.in” file which we
pass through sed to replace some stings (@VERSION@ for example).

The icon file is in the .icns format, you can find plenty of
information about it on the net; also apple ships an icon editor for
that format, as well as the ‘tiff2icns’ CLI util. There are converters
from/to .ico etc. available somewhere on the net, too.

Oh yes, you might notice a special target in the ScummVM Makefile,
which is used to generate a special static linked binary. Two notes:

  1. If you use autoconf/automake, obviously you’ll want to do this
    differently. Exult also uses automake, but so far I haven’t gotten
    around of creating an “exult-static” target for it; I’ll do that
    eventually, though
  2. We use “sdl-config --static-libs”, but note that this only works
    correctly starting with SDL 1.2.7 ! I strongly recommend using SDL
    1.2.7 when working on Mac OS X.

Another one, how do I build an installer? Is there any Mac-specific
"official" way, or people use third-party installer builders (the
equivalent of NSIS, for example)

Good mac apps do not need an installer. They are installed by drag &
drop. So a typical distribution format is to pack your application, the
docs, etc., into a folder; then either compress that folder (as a .sit,
or if you don’t make use of resource forks, you could also use .zip);
or nowadays even more common, people create a .dmg disk image file
(with Apple’s “Disk Copy”, resp. “Disk Utility” tool, or with
equivalent CLI commands). You then put your app on that virtual disk,
and distribute the .dmg file.

Cheers,

MaxAm 04.03.2004 um 05:41 schrieb Sam Lantinga:

Date: Wed, 3 Mar 2004 12:36:04 -0300
From: “Gabriel Gambetta”
Subject: [SDL] Mac OSX - HELP!

Hello Max,

In Mac I find I can install an “application” which seems to be
a whole directory tree. How are these things built? It’s just a
directory whose name ends in “.app”?
Essentially, yes, but with a special structure.

I got it to the point of almost running - except that my game starts
in the directory I’m when I launch it (the one that contains the .app
folder) while I expected it to run in Game.app/Contents/MacOSX, where
the binary is and where the other files are. Do I need to explicitly
extract the directory from the command line (argv[0]) and chdir there,
or is there a way to make it happen automatically editing the plist or
something? I don’t find much about this in Google, which makes me think
it should be pretty obvious.

Another one, I’m not sure whether I’m linking with the dynamic SDL libs
or not (I must use the dynamic libraries). sdl-config outputs the same
with --libs and with --static-libs (–static-libs outputs a couple other
libraries but the SDL parameters are the same). Should I specifically
tell the linker to use the .dylib files? -lSDL.dylib?

Thanks a lot,
–Gabriel

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy

Sorry for the offtopic - my intention wasn’t to send that
message to the whole list :frowning:

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy

It’s best to start with the Xcode template when it comes to making
bundled applications on osx (the .apps). The current directory is not
standard when an application is launched by the finder. Some libraries,
just by linking to them, seem somehow to change it. However, you can
always just use argv[0], with the file name stripped out. Also, I would
put resources in .app/Contents/Resources instead of directly
in Contents/MacOS. While not strictly necessary, it is convenient
because that’s where they are put when you add them to your xcode
project by default.

As for static linking of SDL: You will have to compile SDL from source
to do a static link. The framework is actually just a .dylib wrapped in
a convenient package with the header files.

Jeremy BellOn Mar 9, 2004, at 10:41 AM, Gabriel Gambetta wrote:

Sorry for the offtopic - my intention wasn’t to send that
message to the whole list :frowning:

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I got it to the point of almost running - except that my game starts
in the directory I’m when I launch it (the one that contains the .app
folder) while I expected it to run in Game.app/Contents/MacOSX, where
the binary is and where the other files are. Do I need to explicitly
extract the directory from the command line (argv[0]) and chdir there,
or is there a way to make it happen automatically editing the plist or
something? I don’t find much about this in Google, which makes me think
it should be pretty obvious.

If you launch from the Finder, argv[0] has the full path to the binary,
which you can parse. Your “current working directory” will be “/”,
though. Plan accordingly.

If you don’t launch from the Terminal, argv[0] may be a relative path,
or no path at all if the binary was in your $PATH. The current directory
is wherever the shell is when you launch the program from the Terminal.
Plan accordingly.

There are also Carbon APIs to determine the current process id, and the
location of the filesystem entry that relates to that process, which
might be easier, or not.

Parsing argv[0] is useful because the same code works on Linux (minus,
maybe, chopping off “Contents/MacOS” to get at the base of the app
bundle).

libraries but the SDL parameters are the same). Should I specifically
tell the linker to use the .dylib files? -lSDL.dylib?

-lSDL will use the dylib by default.

–ryan.

If you launch from the Finder, argv[0] has the full path to the
binary, which you can parse. Your "current working directory"
will be “/”, though. Plan accordingly.

If you don’t launch from the Terminal, argv[0] may be a relative
path, or no path at all if the binary was in your $PATH. The
current directory is wherever the shell is when you launch the
program from the Terminal. Plan accordingly.

I dumped argv[0] and looked at it in the various cases; I just parsed
the path and chdir() to it. It worked fine in all the cases I tried.
I hope there’s nothing inherently wrong with doing that…

libraries but the SDL parameters are the same). Should I specifically
tell the linker to use the .dylib files? -lSDL.dylib?
-lSDL will use the dylib by default.

I want to distribute the dynamic libraries with the game; in Windows
it’s
just a matter of having the DLLs in the application directory, can I do
the same with the .dylib files?

Thanks,
–Gabriel

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy

Luckily, I am now on the mailing lists, so I got your mail, even though
you never sent it to me … =)

If you launch from the Finder, argv[0] has the full path to the
binary, which you can parse. Your "current working directory"
will be “/”, though. Plan accordingly.

If you don’t launch from the Terminal, argv[0] may be a relative
path, or no path at all if the binary was in your $PATH. The
current directory is wherever the shell is when you launch the
program from the Terminal. Plan accordingly.

I dumped argv[0] and looked at it in the various cases; I just parsed
the path and chdir() to it. It worked fine in all the cases I tried.
I hope there’s nothing inherently wrong with doing that…

A much cleaner way, also it requires Mac OS X specific code, is to use
the Bundle API. E.g. use CFBundleGetMainBundle() to get a CFBundle for
your app bundle, then use other APIs to retrieve files from your
resource dir, get POSIX file paths etc. etc.

libraries but the SDL parameters are the same). Should I specifically
tell the linker to use the .dylib files? -lSDL.dylib?
-lSDL will use the dylib by default.

I want to distribute the dynamic libraries with the game; in Windows
it’s
just a matter of having the DLLs in the application directory, can I do
the same with the .dylib files?

No. However, you can include the SDL.framework inside your .app bundle
(but you need a special version of the Framework for that. See
ahttp://developer.apple.com/documentation/MacOSX/Conceptual/
BPFrameworks/Tasks/CreatingFrameworks.html#//apple_ref/doc/uid/
20002258/BAJJBIEF.

Any if your project is GPLed, you can even static link SDL w/o
violating the LGPL.

Cheers,

MaxAm 10.03.2004 um 16:18 schrieb Gabriel Gambetta:

Gabriel Gambetta wrote:

I got it to the point of almost running - except that my game starts
in the directory I’m when I launch it (the one that contains the .app
folder) while I expected it to run in Game.app/Contents/MacOSX, where
the binary is and where the other files are.

This is done by the method “setupWorkingDirectory:” in SDLMain.m. You can
change the contents of that method if the default doesn’t suit your needs,
e.g. replace it with
chdir([[[NSBundle mainBundle] resourcePath] UTF8String]);
to have it change to the “Resources” directory.

(Actually, now that I think about it, I’m not sure if “UTF8String” is the
right thing - I didn’t test whether that works with paths containing
non-ASCII characters.)

-Christian

This used to work, but I’m not sure if it still does: just put the
dylibs in the same folder ass your .app bundle, but not IN the .app
bundle. I think I remember this not working recently, but I’m not sure.
Same goes with frameworks, though with the SDL framework version you
can put the framework into .app/Contents/Frameworks

Jeremy BellOn Mar 10, 2004, at 10:18 AM, Gabriel Gambetta wrote:

If you launch from the Finder, argv[0] has the full path to the
binary, which you can parse. Your "current working directory"
will be “/”, though. Plan accordingly.

If you don’t launch from the Terminal, argv[0] may be a relative
path, or no path at all if the binary was in your $PATH. The
current directory is wherever the shell is when you launch the
program from the Terminal. Plan accordingly.

I dumped argv[0] and looked at it in the various cases; I just parsed
the path and chdir() to it. It worked fine in all the cases I tried.
I hope there’s nothing inherently wrong with doing that…

libraries but the SDL parameters are the same). Should I specifically
tell the linker to use the .dylib files? -lSDL.dylib?
-lSDL will use the dylib by default.

I want to distribute the dynamic libraries with the game; in Windows
it’s
just a matter of having the DLLs in the application directory, can I do
the same with the .dylib files?

Thanks,
–Gabriel

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

This used to work, but I’m not sure if it still does: just put the
dylibs in the same folder ass your .app bundle, but not IN the .app
bundle. I think I remember this not working recently, but I’m not
sure. Same goes with frameworks, though with the SDL framework version
you can put the framework into .app/Contents/Frameworks

This is a very bad idea to do for a shipping product. For example, if
your user moves the app out of its install location, it’ll suddenly
stop working for no apparent reason.

Either static link (only possible if you are (L)GPLed), or embed the
framework (really easy to do, see the link in my previous post).

Bye,

MaxAm 12.03.2004 um 06:07 schrieb Jeremy Bell:

You might do this if you have a folder containing your application and
several sub folders that the user may use for plugins, etc… Also if
you have two or more applications which use the same framework, you may
want to do this to cut down on the size of your apps instead of
bundling a copy into each one. Generally, even mac users understand
that usually if an app comes in a folder that you should keep the in
tact, though you are able to move the folder around as a whole. But,
you’re right. Preferably the app should be a completely self contained
bundle that you can move anywhere you like. This is perhaps an option
for certain situations.

(heh, I took longer to write this email than I would have verifying if
this is even possible).

Jeremy BellOn Mar 12, 2004, at 11:12 AM, Max Horn wrote:

Am 12.03.2004 um 06:07 schrieb Jeremy Bell:

This used to work, but I’m not sure if it still does: just put the
dylibs in the same folder ass your .app bundle, but not IN the .app
bundle. I think I remember this not working recently, but I’m not
sure. Same goes with frameworks, though with the SDL framework
version you can put the framework into
.app/Contents/Frameworks

This is a very bad idea to do for a shipping product. For example, if
your user moves the app out of its install location, it’ll suddenly
stop working for no apparent reason.

Either static link (only possible if you are (L)GPLed), or embed the
framework (really easy to do, see the link in my previous post).

Bye,

Max


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl