CVS. It is not agl problem -- try to open demofont.dat with grabber.

Thanks, it was me, but this doesn't solve fonts problem. It would be nice to hear someone from AGL team about last 3 patches I sent though.

Don't worry. In order to make a giant leap, you have to bend your legs a little.

Yeah, I just made that up and it shows. It also shows that it's waay past my bedtime. Anyway, there was the 4.2 deadline to deal with, and this is still labelled 4.20b, right? Let's get to it and squash bugs!

I think there is too little time between our 'private test release' and actual release. There should be at least 48 hours.

I think undid most of the damage I did and the current download should compile and work without major show stoppers.

Milan: I had intended to have it finished on Wednesday, but it was not to be. Since everything was fine a few days ago, things worked fine for me and people reported that it worked this morning, I decided I could afford to make the release. Clearly, the problems were with last minute fixes and things I mistested that didn't show up in a cursory run of the test programme or the examples. Should be sorted out now.

Huh? Please double-check that. The rule is there in my local tree, which is synchronized to the CVS tree. Also please check with the source archive on the download page.

Evert, makefile.all is still messed up. Now it's using backslash for the UNIX script, which won't work under MSYS (and neither under Cygwin, I presume).

Sounds good. BTW, pretty annoying that my patch to use "cd misc; mdhelper" hasn't made it through to the mailing list yet. I sent it almost four hours ago! Of course, the patch is no good for Windows 9x, but I presume that's not the reason it's not on the list yet. Maybe we should consider looking for alternatives to Sourceforge for hosting the mailing lists? This kind of delay happens quite often, doesn't it?

I disagree. I think the root Makefiles/build system files should be in the project root.

[edit]
If you have the Makefile in a subdirectory, you can't simply run "make". You have to run "make -f subdir/Makefile".

The configure script will create a Makefile in the root directory.

A very simple project with a configure script, windows makefile, and vcproject file has these files. Unless you disregard the above two notices, you can't get the root less cluttered than this.

cgames@arena tinparty $ ls
AUTHORS      Makefile.win    config.h       configure.in  mkinstalldirs
COPYING      NEWS            config.h.in    data          src
ChangeLog    README          config.log     depcomp       stamp-h1
INSTALL      TODO            config.status  install-sh    tinparty.dev
Makefile     aclocal.m4      config.sub     libtool       tinparty.sln
Makefile.am  autom4te.cache  configure      ltmain.sh     tinparty.vcproj
Makefile.in  config.guess    configure.bat  missing

20 of those files we because the configure script existed in the directory. You can't lower this number.

That is my idea. Let the fix include the subdirectory (of course, modifying all other makefiles). For everyone else it would be clean (fix ...; make). The configure output could be moved into another directory (inside obj/linux, in example).

It's a beta. It will have errors. You can't go in forever having pre-beta, pre-pre-beta... eventually you have to dive in. Well done Evert for all your work so far

AFAICS, it isn't broken on OS X (this is revision 1.55 of makefile.all) - or have I got that to come...?

Pete

It would be a huge pain to run obj/linux/configure to configure. Every other package on the net has configure in the root. I also don't think the directory is cluttered, as the only things that are ever access from outside the command line are in subdirectories themselves, and those are sorted to the top.

Does 4.2 compile with gcc 2.95? My version doesn't have inttypes.h.

C:\code\allegro>make
Compiling Allegro for MinGW32, optimised. Please wait...
gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=i586 -O2 funroll
loops -ffast-math  -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/all
egro.o -c src/allegro.c
In file included from include/allegro/internal/alconfig.h:64,
                 from include/allegro/base.h:40,
                 from include/allegro.h:25,
                 from src/allegro.c:23:
include/allegro/platform/astdint.h:28: inttypes.h: No such file or directory
make: *** [obj/mingw32/alleg/allegro.o] Error 1

I have no problems if that is the solution. However, the build process should detect that and tell you nicely if it is the case - considering that (at least most versions of) Allegro 4.1.x compiled with 2.95.

We modem users don't like upgrading unless absolutely necessary.