'sudo install-framework EMBED=1' has the effect of building a version of the Allegro framework that is suitable for embedding into projects. However, the ever-decaying Project Builder project template doesn't attempt to do so. You are absolutely right that there is no obvious way to adjust the template.

However, there is a non-obvious way. On your target, right click and select "Add->New Build Phase...->New Copy Files Build Phase". In the menu that then comes up, switch the copy target from 'Resources' to 'Frameworks'. Close that dialogue, then do a copy drag (ie, start dragging, then hold down alt/option before dropping — same as the the Finder) of the Allegro framework from the 'Link Binary with Libraries' phase to your new copy phase.

Next time you build, Xcode will embed the framework for you. Assuming it was correctly built as embeddable, you should then be good to go. A good way to test on your own machine is to temporarily remove Allegro.framework from /Library/Frameworks and try to run your application.

A little movie is attached of me doing the above steps in Xcode 3.1. I'm a bit of a traditionalist, so I use the 'Condensed' Xcode layout, but I'm sure you can figure out what to do if you're an 'All-in-One' or 'Default' sort of guy.

Click the paper clip at the top of Thomas Harte's post and a little list will pop up with the video file in it

Ok,
when I do the otool thing on my Intel mac, it returns successful, however I do not have any other intel macs to test the games built on it (the rest of my macs are all ppc, unless theres some way to make them universal?)

But when I try running the otool on my ppc mac (running Tiger) that's setup for allegro development, it returns
"liballeg-4.2.dylib"

and when i try the 'install_name_tool -id @executable_path/../Frameworks/Allegro.framework/Versions/4.2.2/Allegro Allegro.framework/Allegro'

i get:

install_name_tool: can't open input file: Allegro.framework/Allegro for writing (Permission denied)
install_name_tool: can't lseek to offset: 0 in file: Allegro.framework/Allegro for writing (Bad file descriptor)
install_name_tool: can't write new headers in file: Allegro.framework/Allegro (Bad file descriptor)
install_name_tool: can't close written on input file: Allegro.framework/Allegro (Bad file descriptor)

This wouldn't be a problem if there was a way to make the apps universal so they'll work on Powerpc's after being compiled on intel; can it be done? This would be a lot easier too as I could do all of my development on my better intel mac.

I really appreciate all your help, haha, thanks:D

Oh, looks like Allegro copies its stuff so that everything is flagged modifiable by the root user only. To fix the permission/file descriptor issues, do this first:

su [any username with administrator privileges]

If the username has a space in it, you'll need to add a slash before it, e.g. if your user was "The LHP" you'd need:

su The\ LHP

That'll require you to enter the password for that user. You can then use:

sudo install_name_tool [the stuff I said before]

To have Allegro make a universal version of itself rather than one that is processor specific, you need to go almost right the way back to the beginning and do ./fix.sh macosx-universal rather than ./fix.sh macosx prior to letting Allegro make and install itself. Allegro's build system is tetchy and ever more broken (Apple keep moving goalposts, Allegro has barely any Mac developers), with the effect that it doesn't seem to successfully make a universal version for a lot of Intel users with 10.5. So it's probably safest to do the universal build on a PowerPC. Maybe you'll even get lucky and this build will make an embeddable version of the framework without you having to do a lot of manual UNIXy stuff yourself.

I have an Intel machine without Allegro installed (well, close enough — I forego the UNIX-style installation that scatters things among obscure fixed-path locations, with the result that I can install and uninstall my copy of Allegro very easily), so if I can test anything then feel free to attach it. While it's a matter of testing your installation, I think it remains relevant for this section of the forums.

My assumption is that you'll probably need to do a separate universal build on every machine you want to use for development. You can't simply copy the Framework because Allegro also relies upon the static library liballeg-main.a. Alternatively, grab the Framework and liballeg-main.a and take them to your development machine. As I don't allow Allegro to squirrel things away, I don't recall where it normally puts liballeg-main.a.

Personally, I tend to let Allegro 'make' but not 'make install', I copy the complete set of headers into the Framework along with liballeg-main.a, then copy that by hand and set Xcode to reference it in my Allegro project template. No obscure UNIXyness, no fuss. It's absolutely a personal preference decision though, a lot of people love UNIX and commandlines and so on.

EDIT: Arthur's suggestion of chown would work as an alternative to su and sudo. Similarly, I guess you could go to /Library/Frameworks in the Finder, bring up the Info on Allegro.framework and set the permissions in there (it'll ask for an administrator account username if yours isn't an administrator account and for your password) and make sure you have the privilege level for you set to 'Read & Write' under Sharing & Permissions, as I do here:

{"name":"598946","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/5\/c51023699f34cb9fa46b56afa3cc635d.png","w":345,"h":912,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/5\/c51023699f34cb9fa46b56afa3cc635d"}

Yep, yep, runs just fine. And at just 45% CPU, which is refreshing for an Allegro program. I'm on an original Core Duo MacBook Pro 2.16Ghz from mid-2006 if that helps add detail to the off-topic issue.

Sorry, wading way off topic for this section of the forum, so I'll be brief. For years the standard advice in the Allegro world was "occupy 100% of the CPU, who cares?". That's fine for vanilla Pentium PCs, but obviously atrocious for any computer designed around thermal or power usage considerations, including every current Mac and 90% of PCs. Obviously you've done something to limit CPU usage as much as you can, which is very good. And didn't cause my fans to go into can-almost-no-longer-hear-the-audio mode.

It wouldn't surprise me. Of the versions of Windows I possess, Windows 2000 is a lot more efficient in a virtual machine than Windows 98, so I suspect the whole DOS line might be blighted. Completely unnecessary, of course, because the display can continue to function without CPU intervention and the keyboard input generates interrupts. And so does the clock, for the purposes of TSRs. But that was an age before anyone cared about power management, when the computer had one fan only, on the PSU. I definitely had a P200 that was passively cooled, so anecdotally I reckon the turning point for shoving fans everywhere was after that, and I guess the reaction to use as little power as possible so as to keep the fans off when possible is around the same period. And now that laptops are the dominant consumer form factor, preserving battery power is a concern in addition to thermal issues.

And you heard it here first: don't use Linux, it'll frost up your motherboard real bad.