Pole Position from the Atari... plus you have the modern remakes of it and those little games you plug into the tv that have older games on it.

If only I had OS X in VMWare...

Oh, I've patched my copy of Allegro so that I don't have to live with its stupid internal folder naming. So that's one obvious area in which our application bundles vary. Otherwise I note you have the framework embedded whereas I definitely do not, and I'm following that observation up in the correct forum.

Well, I'm annoyed now because Firefox 1.5 has once again decided that switching from one tab to another means the tab switched to should be reloaded - throwing away my post. It's a good thing I'm not a violent man or I might not have a computer any more.

Anyway, blah blah blah OS X is very straightforward and easy for the end user, bundles make a lot of sense but Allegro is confusing.

A bundle is just a hierarchy of folders and files - like any other folder in the filesystem - except that it is graphically represented to the user as a single icon and if you double click an application bundle then the binary at a particular place in it is launched. Most frequently OS X applications come as .DMG files, which are virtual disk images. You mount the image (by double click), drag the included application bundle to wherever you want to keep it (usually /Applications - some DMGs come with symbolic links to /Applications in them so that you only have to drag the icon about two centimetres even if the other convention of whacking icon sizes up to full size in DMGs is followed), then unmount the disk image (drag the drive to the trash or right click and select eject) and, probably, throw the DMG into the trash too. To uninstall you drag the application bundle to the trash.

Also not uncommon is to see applications distributed as .zip or .sit, which are usually just the application bundle in a more traditional archive format. In the Mac world .sit was a de facto standard before they realised that they weren't somehow masters of the universe able to live in their own bubble with their own standards, etc.

It isn't just applications that are bundled. Ordinary data sometimes is also - for example XCode projects are. So rather than the VC6 collection of a .dsw, a .dsp, a .ncb, etc, you just see one "file" in your project directory.

Bundles are not an OS X invention. They were in NextStep and, presumably independently as both arrived in 1989, RISC OS. Due to their NextStep heritage they also exist in GNUstep. Because the folder conventions are preserved, it would be perfectly feasible to produce an Allegro based fat binary that supported both GNUstep and PPC OS X out of the box as long as you didn't rely very heavily at all on any other common APIs being in place. OS X does retain a lot of its NextStep heritage, e.g. the base class for applications is still NSApplication, the thing representing a bundle is still NSBundle, and most things other than specifics of the widget set are carried over. My guess is that Intel OS X will expect to find its application binary in the same place in the bundle as you'd place an intel GNUstep though, so this possibility probably won't hang around for very much longer.

In a sense the Application framework provides a third option for linking. Frameworks are essentially similar to DLLs and SOs (albeit better at versioning) and may be dynamically linked against as you'd expect. If you build a BSD style lib<whatever>.a then you can statically link against that. But you can also dynamically link against a framework and then include it in the bundle. That gives the usability advantages of static linking in that the user doesn't have to install any special frameworks or in any other way maintain multiple "files". It also means that a competent user could update the embedded framework with a newer version if they chose, so brings LGPL compatibility.

Allegro has been a confusion. As you see, Matthew prefers to use the commandline and does a reasonable amount by hand. I prefer to use XCode, the Apple |DE. As it turns out the project template provided by Allegro doesn't embed the framework even if you've built it to be embeddable. You'll see I've posted instructions to fix that to the Installation, Setup & Configuration forum + a substitution project template for users of XCode 2.0 or above. Now, when I press XCode's build button (or hit command+b!) it does everything necessary and leaves me with a perfectly formed bundle - no manual copying or editing of anything. So the process is really as simple as it could possibly be.

To Matt:

As you're at the commandline, have you performed

export MACOSX_DEPLOYMENT_TARGET=10.2
export NEXT_ROOT=/Developer/SDKs/MacOSX10.2.8.sdk

And added -L/Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/gcc/darwin/3.3 to your linker somewhere so that you aren't just building for whatever version of OS X you have and upwards?