I'm a real building things dunce, and a UNIX dunce, and generally really bad at all of this stuff. This probably means I can't come up with a complete solution on my own.

However, if you go to the Targets tab and expand the 'AllegroNew' target, you'll see all the steps that Xcode will go through in order to build Allegro. The first step is 'Run Script', which is currently empty. If you can write a suitable shell script to configure Allegro then you could just put it in there. I guess even just a script that calls cmake is helpful, one that doesn't require cmake to be installed would be even better.

EDIT: here, assuming you use the Project Builder-style "lots of windows" presentation rather than the more Windowsy "all-in-one" look:
http://www.allegro.cc/files/attachment/596604

That's not really true.

To launch an application bundle from the Finder: double click.
To launch an application bundle from the shell: "open <whatever.app>"

'Open' works on any kind of file or bundle that Finder understands, and correctly respects resource fork preferences. So if your default application for handing .doc files is NeoOffice, but you've tagged that particular one to open with MS Word (by doing command+i and selecting Word from the 'Open with' drop-down) then it'll open with Word.

The Allegro-built UNIX-style binaries cannot be launched from the Finder or even from most places in the command shell because they make incorrect assumptions about the current working directory.

As per usual, please don't think that my brief writing style implies a harsh tone, what you've done and what you're doing is fantastic. I'm one of the many people that stopped using olde Allegro years ago due to its uncountable flaws, and I didn't realistically expect anyone to relaunch the brand as you are doing.

Pity

Hmm... that would presumably be a script that has to do the same things that cmake does, right? And presumably it'll have to be written in BASH or something similar?
I've seen the "Run script" thingy in XCode, but I have no clue how to actually make it do anything (well, I haven't really tried that hard).

I know, as I said, you can't "easily" start them. You have to type "open" first followed by the full path of the application bundle. And if you want to pass a filename as a commandline argument as well it's worse, because then it's open -a full-path-to-application full-path-to-filename. Anyway, that's what shell scripts are useful for.

Personally, I always think of it as a flaw of the Finder that it can't run "naked" executables.

Rather, they assume certain files are placed in the current directory. There is no ambiguity in what the current directory is if a program is started from the shell.

I know - that's why I at least think your input is very useful, and I appreciate your input.

Indeed off-topic, so we shouldn't follow up on this too far:

Relative paths will do (except for filenames you want to pass as arguments - they'll be interpreted as relative to the bundle, or the bundle's data directory), no path at all does not work except in the special case that the application is in the current directory:

How do you mean? Any OSX documentation is likely to be out of date since I haven't written it yet. That has to improve before the next version.

In terms of xcode projects, the AllegroNew one is my own 'development' version from before we got cmake working. So some of it is hardcoded to what I have on my system. It's actually not so easy to do the configuration side of things with xcode, for example searching for a library in more than one place seems to be impossible. It probably should be deleted.

Your best bet is to generate it via cmake
ccmake -G Xcode .
and set the options you want, then you can open ALLEGRO.xcodeproj in xcode or just build it with xcodebuild -project ALLEGRO.xcodeproj. The main problem with this is that none of the exe paths are right, you need to Get Info on the executable and change the working directory.

I want to get the code working, then look into nice packaging (frameworks, project templates) for OS X later.

Pete

Do you know which version of OpenAL you have? Maybe AL_SAMPLE_OFFSET doesn't exist in older versions.

You can just switch WANT_KCM_AUDIO off.

OpenAL is the only option on Mac OS X right now.

I used cmake to generate the makefiles. I didn't mess with any of the ON OFF options when I first compiled and I got the following error.

[ 57%] Built target a5_font_static
Scanning dependencies of target kcm_audio_shared
[ 57%] Building C object addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/audio.
c.obj
C:\Documents and Settings\Christopher\Desktop\allegro\addons\kcm_audio\audio.c:1
5:47: allegro5/internal/aintern_kcm_cfg.h: No such file or directory
mingw32-make[2]: *** [addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/audio.c.o
bj] Error 1
mingw32-make[1]: *** [addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/all] Erro
r 2
mingw32-make: *** [all] Error 2

C:\Documents and Settings\Christopher\Desktop\allegro>

WANT_KCM_AUDIO ON worked for me in 4.94, I don't know what happened in 4.95.

I Then turned WANT_KCM_AUDIO OFF and got this error:

I then turned WANT_TFF OFF

It then compiled.

When I did mingw32-make install, it gave me this error

I would say that you need to delete the cmakecache.txt file from where you are running cmake, then try again. If you created the build directory and ran cmake from there as per the instructions, you could simply wipe that directory and start again. I've noticed too, that sometimes I had to completely delete the allegro directory and start with a fresh backup...happened last night trying different options.:)