... is released. Download.

Holy crap, wasn't there a release a few weeks ago? Who's doing all this work?

Does this now mean if you put your Logic and Drawing functions inside the Allegro timer event, and those force it to run slower than the speed of the timer (thus preventing all of the timer events from being eaten up) the event queue will fill up indefinitely causing massive memory 'leaks'?

Anyone know if it builds with msvc 9?

Yes, including the quotes on the 'leaks'. I guess if you're worried about that you should try to detect if you're falling behind massively (e.g. compare the timestamp on the event you're processing with al_current_time()) and abort.

Or just not use that abortive timing method in the first place

Anyway, great job A5 devs.

It does.

NICE !
That time I will crash my head on it to make it work !

Doesn't build with msvc 9 for me.

I haven't looked into it, but here's the start of the error messages I get:

Sorry for that, it slipped. To make it compile you can remove the semicolon from each call to _AL_EVENT_HEADER macro in include/allegro5/events.h.

I counldn't get it installed. I've got Dev-Cpp 4.9.9.2 installed on a fully updated Windows XP.

Here is cmake's error

Detecting CXX compiler ABI info - done
Guessed MinGW directory: C:/Dev-Cpp
Performing Test HAVE_DM_POSITION
Performing Test HAVE_DM_POSITION - Failed
CMake Error at CMakeLists.txt:195 (message):
  Missing DM_POSITION.  Please update your MinGWw32api package, delete
  CMakeCache.txt and try again.

I downloaded the latest binary release from mingw and told cmake to use that compiler. Cmake said the compiler wouldn't pass a simple test.

I'm a bit worn out from downloading and installing so many packages, I need a break and then I'll try again.

Did you follow the instructions provided in that error message? It said to update just the w32api package. Get the absolute latest w32api package and extract it over your current compiler directory.

What's the deal with providing an Xcode project, then claiming that it doesn't exist in the readme?

I got some strange errors too using mingw32 and cmake on WinXP Pro SP3.
I downloaded the dx9 package from Trent's site.
It's crashing due to a syntax error after asm, ; = + ...
I'am still searching why.

Edit:

Edit2:
-There is a alplatf.h.cmake instead.
Edit3:
-I edited it, commented all the unnecessary stuff, reconfiguring, regenerating makefiles, and mind what, it's currently compiling ! (20% done)
Edit4:
Still Failing !

cmake should have generated alplatf.h, if ti didn't likely there was an error.

Looks like c++ is missing.

Well, I can ensure you that g++ is present. I got the full mingw32 package.

It's only a go-between while we didn't have a proper build solution for Macs. It will probably be deleted soon. Instead, you can use cmake to generate an Xcode project. The difference is cmake will detect external dependencies on your system.

Fixed

Works For Me. And that's all that matters.

Still doesn't build with msvc 9, linking errors now. I'll try again when the next release is ready.

Try to be constructive.

If cmake is for some reason not working properly on your system, it likely has something to do with your system (because it does work for others). Doesn't mean we shouldn't get it fixed. Did you check if you have the latest version of CMake?

Does it even work properly? I couldn't build Allegro [4.9] at all on my Mac until CMake worked there (ok, so I probably have some dependencies installed in odd places).

We have a better chance of fixing said linking errors if you tell us what they are.

I using mac osx 10.4, With it's default Xcode gcc compiler, and I'm trying to compile Allegro 4.9.5 with the newest version of scons (because I get more errors with Cmake)

It only detects the library png and library jpeg add-on things at the top (makes scene, since I only have those two)

It compiles alright but has a linker end when it's trying to link together liballeg-4.9.5.dylib

Am I missing OpenGL or something?

p.s. If this is the wrong place to post this, sorry.

I've never tried Scons, but I can tell you that it works for me with CMake on essentially the same system.
So please post the error that you get from CMake. I don't think anyone has tried Scons on OS X.

(Aside: it might be useful if the developers can post what systems we have all used to test and compile Allegro, so that people know what has been tested/should work? It will likely help in finding and fixing bugs).

No, I don't think so. It looks like it's not passing proper compiler switches to libtool, but I have no idea.

This is exactly the right place to post this.

I've only gotten preliminary support for OSX with scons right now (and Windows too). I'll get around to fixing the linker errors some day, but if you'd like to help out you could hack the scons files to add in the proper linking lines. It probably involves seeing how xcode does things.

After I manually removed all the OGG links and commented out the definition of ALLEGRO_CFG_ACODEC_VORBIS in aintern_acodec_cfg.h it built libAllegro-4.9.a and ex_bitmap. I had to manually shuffle files around to test that ex_bitmap worked since the project build a UNIX-style executable (YUCK!) and puts it where it cann't find Mysha.

My natural assumption with anything like this is that I'm probably doing it incorrectly. It's obviously really hard to tell when there is no documentation (well, other than "We provide two build systems, CMake and scons.").

Oh yeah, 36 unused variables warnings, by the way.

Best look how it's done through CMake instead.

Hmm...
That's not nice. You know more about using XCode than I do (and quite possibly more than the other developers do either). Using CMake to generate the XCode project file will generate an XCode project file with dependency information and library locations set properly. Is there any way to do that from within an existing XCode project file without using CMake? If so, can you provide an XCode project file that does that to replace the one we have now?
Otherwise, as Peter said, the best we can do is tell people to generate one with CMake.

It's exactly the same executable as when you put it in a bundle, except for directory structure. Packing all of the examples as bundles is obviously possible and probably something we should do, but probably not the highest priority at the moment.
Besides, application bundles are annoying - you can't easily start them from the command line.

Out-of-source build with CMake does that too.

Those are the ones we have that are tested. As it says, the XCode project file is there but I don't know if anyone has made an attempt at keeping it up-to-date and functional. If you're willing to help out in that capacity (I have no idea how much work this would be), please do!

Yup. We'll get round to fixing that eventually. I checked a few of them and I think they were due to stub functions that had to be filled in. Not sure though.

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.

update to my build report:

After setting INCLUDE, LIB and LIB_PATH to the appropriate directories of the DX9SDK(Aug2008 edition), the cmake "Could NOT find..." errors for D3D9 and DSOUND were gone.

The build of the solution still fails though with unresolved externals:
http://www.allegro.cc/files/attachment/596605

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.

Re: doing the same stuff cmake does, I guess so. I'm not 100% on what cmake does other than vague notions about looking in common places for common things, so...

Re: BASH. Yep. If you double click just the Run Script tag then you'll see the automatically generated script that Xcode uses. Here:

http://www.allegro.cc/files/attachment/596606

So I guess you could use any scripting language for which an interpreter is present on the system — bash, perl, whatever. Thinking about it though, you'd probably have to do some fancy footwork to change the link stage. I'll look into it and report back if I figure anything out.

Well off the point, but you don't have to type the full paths, relative paths will do. Or no path at all.

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:

and another update on my build report:
As instructed by Milan on IRC (thanks again), I deleted the CMakeCache.txt and removed "_al_release_event" from the allegro.def file and finally the build was successful and all the unresolved external symbol errors were gone.

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

I ran the cmake build, and I didn't notice that it had actually built (both .dylib libs and static .a libs) liballeg-4.9.5, liba5_iio, liba5_font.

It was just getting error when it was compiling the kcm_audio addon

/Users/Johnathan/src/allegro-4.9.5/addons/kcm_audio/openal.c: In function '_openal_get_voice_position':
/Users/Johnathan/src/allegro-4.9.5/addons/kcm_audio/openal.c:643: error: 'AL_SAMPLE_OFFSET' undeclared (first use in this function)
/Users/Johnathan/src/allegro-4.9.5/addons/kcm_audio/openal.c:643: error: (Each undeclared identifier is reported only once
/Users/Johnathan/src/allegro-4.9.5/addons/kcm_audio/openal.c:643: error: for each function it appears in.)
/Users/Johnathan/src/allegro-4.9.5/addons/kcm_audio/openal.c: In function '_openal_set_voice_position':
/Users/Johnathan/src/allegro-4.9.5/addons/kcm_audio/openal.c:656: error: 'AL_SAMPLE_OFFSET' undeclared (first use in this function)
make[2]: *** [addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/openal.c.o] Error 1
make[1]: *** [addons/kcm_audio/CMakeFiles/kcm_audio_shared.dir/all] Error 2
make: *** [all] Error 2

Also I tried to install a packaged OpenAL from it's Official Website, but I'm not sure it helped.

Is liballeg-4.9.5.dylib all I need to start out anyway?

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.

OR just switch off OpenAL.

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

Per readme_a5.txt:

Compilation
===========

We provide two build systems, CMake and scons.

Obviously I was taking this too literally; it should be "We support two build systems", since you provide at least three.

Could you not get Xcode to link via a symbolic link in the project tree, and have a script set up the link correctly in the 'Run Script' phase?

Absolutely the correct approach.

The static lib built fine apparently.

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

There is a series of errors caused my cmake not generating a *.h file from *_cfg.h. How did you invoke cmake exactly?

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.:)

I ran the cmake gui.

Edit:

It worked with no error using the command console in windows. Thanks for the help.