I invite you to test allegro 4.3.11 SVN some more. What I'm most interested in is the build system, especially the macosx-universal target for addons. The most recent SVN snapshots can be found at http://www.strangesoft.net/allegro/
These packages are ready to be built, just like the normal releases.

All 6 versions of the stand alone allegro compiled fine with MinGW 3.4.5 on Vista for me.

Aside from building each add on separately, how do you enable building them at the same time?

The two warnings refer to the functions do_ellipse and _soft_ellipsefill which start at lines 1095 and 1238 respectively. The way both functions stand now is that both instances of midway_x are guaranteed to be given the value of the variable x before either one is referenced, so it wouldn't hurt anything to initialize midway_x to zero, and it would get rid of the warnings during the build process.

I'm moving on to build the add ons now.

Downloaded 4.3.10plus from your site, Milan. The base library built fine but the addons couldn't link for want of the allegro-config file which was nowhere in the base directory (`../../allegro-config... etc.`).

intel iMac 10.5.6 xcode 3.12

-Paul

He's really only interested in 4.3.x (which would be the 4.3.11 version, not any of the 4.9.x downloads).

I think you pretty much have to install allegro before working on the addons in 4.3. I'm not 100% sure about that though.

make WITH_ALLEGRO_GL=1 WITH_LOADPNG=1 WITH_LOGG=1 WITH_JPGALLEG=1
Building them separately might not even work. I've also added a WITH_ALL_ADDONS in SVN now.

No, you're not supposed to install first. Oh, I didn't notice that on OSX allegro-config is generated on install.

The latest snapshot built and skater_agl ran perfectly. I didn't test anything else. MinGW gcc 4.2.1.

Rev. 11360 failed to build for me with this error:

make[1]: Entering directory `/home/paul/src/allegro-4.3.10plus/addons/allegrogl'
gcc -o obj/unix/release/x.o -Iinclude -Iinclude/allegrogl -Iinclude/allegrogl/GLext -I../../include   -O2 -Wall -ffast-math -fomit-frame-pointer -fPIC -c src/x.c
src/x.c: In function ‘allegro_gl_x_create_window’:
src/x.c:1080: error: ‘struct _xwin_type’ has no member named ‘override_redirected’

GCC 4.3.2 on Linux

SL: fixed it

I am attempting to compile it with cygwin, I got the base allegro built, but when I go to compile a test application...

#include <allegro.h>

int main()  {
  allegro_init();
  allegro_message("Hello World!");
  return 0;
}
END_OF_MAIN()

I get the following...

$ gcc test.c -o test.exe -lalleg
In file included from /usr/local/include/allegro/internal/alconfig.h:44,
                 from /usr/local/include/allegro/base.h:41,
                 from /usr/local/include/allegro.h:25,
                 from test.c:1:
/usr/local/include/allegro/platform/almngw32.h:24:23: direct.h: No such file or directory

The only relevent direct.h is in "h:\cygwin\usr\include\mingw", forcing that into the include path gave me...

$ gcc test.c -o test.exe -I /usr/include/mingw -lalleg
/cygdrive/c/DOCUME~1/Timmy/LOCALS~1/Temp/cczsl7bl.o:test.c:(.text+0x7): undefined reference to `__errno'
collect2: ld returned 1 exit status

Which isn't really what I wanted. I searched the forum and this has come up before, but there was no solution posted.

I am not sure where to go from here. Any help will be greatly appreciated, I am going to try the current version (4.2.2) to see if it has the same problem.

On the plus side, allegro did actually compile.

Edit:
4.2.2 compiled with ALLEGRO_USE_C=1, but when it came to the test program, I get exactly the same problem.

When compiling with the cygwin's gcc you have to pass -mno-cygwin to it. Then it will act like a mingw compiler. This actually means that you can't compile or use allegro with cygwin, but you can use a cygwin environment instead of mingw.

No worries, the latest 4.3.x from strangesoft is what I was compiling. By stand alone allegro, I meant without enabling the simultaneous builds of the addons.

Ah, thank you. I'll try using the WITH_* options later. Now that the add ons are being bundled with Allegro, shouldn't the text help files in docs/build/ and docs/src be updated to notify the builder of the new options? Also, it would be nice to have both the dependencies of each add on and their respective licenses noted briefly in the main allegro/docs/[build | src]/platform_build_directions_file, or in a separate readme_addons file.

If the add ons are linking to the allegro library, where are they looking for it at? Do they specify a search path for the linker? In effect, if they're built separately (using the makefiles that come in allegro/addons/*, does allegro need to be installed to the compiler's lib directory?

It looks like AllegroGL needs to have the allegro folder two directory levels up, and adds a search path to ../../lib/$(COMPILER), so it's not linking against the allegro library in the compiler directory. It looks like logg does the same thing, as well as jpgalleg and loadpng. So it doesn't seem that any of the add on targets require allegro to be installed to the compiler directory and that each could be built separately after allegro is built two directories up.

Anyway, I'll try building them separately after I finish compiling zlib, libpng, and the ogg and vorbis libraries.

AllegroGL compiled fine for all [optimized | debug][dynamic | static] targets separately using the makefile in the addons/allegrogl folder.

I'm having some problems building jpgalleg though :

The 'all' STATICLINK=1 target built okay, both the lib and the examples, but then the 'all' STATICLINK=1 DEBUG=1 target didn't recompile the object files for the library or the examples, and immediately relinked the library. After that, both the debugging and non-debugging versions of the 'all' target failed, as can be seen in the log above (and neither tried to recompile any object files either).

Compiling libpng and zlib has been just about the least fun thing that I've done in a while. I had to manually install everything because they don't understand Windows doesn't have *NIX commands, except for the ones provided by MSYS, and that would install them in the wrong place for me. At least MSYS lets me use the configure scripts.

From reading the loadpng makefiles, it doesn't have any option for a debugging build, and it doesn't use separate names for the static and dynamic libraries... because there's no dll build, and STATICLINK=1 only seems to apply to the example programs it creates (only a statically linked .a archive is created). Other than that, loadpng compiled fine, except for some deprecated function warnings for browse.c.

That's enough for today though. Tomorrow I'll pickup ogg and vorbis, and compile logg.

Hm, seems that the deocs are only halfway generated. Run "make docs" and docs/txt/addons.txt and others should appear.

That's right.

I'll look at the rest later.

Okay, now I have addons.html, addons.rtf, and addons.txt in their respectively named format folders ( I may have had them before though, but I didn't check ), but there's no addons.txt in the build folder. It makes sense to me to have 'targets.txt' and 'addons.txt' come with the distribution in the docs/build folder, but that's up to you guys.

OK, revision 11485 should have the JPGAlleg issues fixed. I made it place each configuration's obj files into a separate dir.

logg and loadpng just don't support anything like DEBUG or STATICLINK. STATICLINK=1 is default and that's it.

I can confirm that, thanks. Everything built properly.

Here is the error I got:

I am using mingw 3.4.5 on windows XP

Got the source from http://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.3.10plus/

When you get allegro directly from SVN you have to run "make depend", among with many other things... So better use the snapshots I gave a link to.

Okay, I tried rev 11485 and had the same problem with `../../allegro-config --libs --addon` not finding the allegro-config file. Allegro GL compiled, but the examples do not. I installed the lib first, anyway, before going into the GL addon folder. I see allegro-config.in but autoconf is not doing anything with it(?). All the other addons looked for allegro-config also. What am I doing wrong? (I'm just going: chmod +x fix.sh / ./fix.sh macosx / make)

iMac intel 10.5.6

--Paul

lemranger: find where on is allegro-config on your system and copy it into the allegro build dir. This is a workaround for a rather big design flaw.

The newest one compiles fine for me

I managed to compile the logg addon sucessfully after coming up with a workaround for some trouble with getting libvorbis to compile correctly. It would be nice if the play_ogg and stream_ogg example programs from logg let you quit before the music is finished though.

If anyone's having trouble compiling libvorbis because of undefined references to ogg functions, you can try my workaround for it.
(Use 'export LIBS=-logg' in MSYS before running configure and make)

@Milan
Thanks for reconfiguring jpgalleg, I'll try the latest strangesoft package tomorrow.

Okay Milan, it all worked!
The install put the allegro-config in my /usr/local/bin (where it is supposed to go) but I guess the direct reference to it (../../allegro-config) passed that by. I copied the file to the build directory and everything compiled and I tried all the examples without any problems.

intel iMac 10.5.6 xcode 3.12

--Paul

Press Ctrl-C . Can't get input without creating a window in Linux, so to be fair they're console apps.

Ctrl C doesn't work, not from the console or the program, so If I want to stop it early, Task Manager has to be used. You could use getc and rest.

Ctrl+C should work in a console window, unless there is an interrupt handler that overrides it.

Nevermind. Ctrl ^C works from the console after you switch back to it.

Edit
The links to the snapshots on the strangesoft download page are coming up with 404 Not Found errors. I'll try again later.

Edit2
All better now, downloading 4.3.11r11485 to test tomorrow.

Edit3
The downloads for both the .7z and .zip archives of 4.3.11r11485 keep failing midway through without any error messages. SeaMonkey seems to be keeping a cache of what it downloaded of it, so when I go to download it again it starts back up where it left off, but somethings funny.

Sorry about the 404's I was messing with the index script today. Felt like making it a little fancier, and I was having issues with mod_rewrite.

All I can say is I've downloaded the zip just fine, and it was fairly fast too. like 600KB/s or more.

All the versions of Allegro 4.3.11 Rev. 11485 compiled fine again, with one warning from the profiling static version (only) :

c:\mingw\allegro-4.3.11plusSVN_11485>mingw32-make STATICLINK=1 all
.....
tests/test.c:4637: warning: zero-length printf format string

All 4 versions of AGL compiled fine again, as well as Logg.

Still some trouble with JpgAlleg though :
In jpgalleg's makefile.all file, there is a line (149-151) that tests for DEBUGMODE being defined, in which case it defines DEBUG=1, but that is after several tests that check for DEBUG being defined, and after the $(MAKEFILE_INC) file is included (which also relies on DEBUG being defined), so it would miss both of them.

I'm also having problems building the non-static versions of the jpgalleg addon. I attached a text file of the build log (I'm using the DEBUG=1 option until DEBUGMODE is sorted out).

Errors (from allegro/addons/jpgalleg/ dir) :

//
gcc -s  -L../../lib/mingw32 obj/mingw32/ex1.o -o examples/ex1.exe lib/mingw32/libjpgad.a -lalleg
Info: resolving _screen by linking to __imp__screen (auto-import)
Info: resolving _allegro_error by linking to __imp__allegro_error (auto-import)
fu000001.o:(.idata$2+0xc): undefined reference to `lib_mingw32_liballeg_a_iname'
fu000002.o:(.idata$2+0xc): undefined reference to `lib_mingw32_liballeg_a_iname'
fu000004.o:(.idata$2+0xc): undefined reference to `lib_mingw32_liballeg_a_iname'
nmth000000.o:(.idata$4+0x0): undefined reference to `_nm__screen'
nmth000003.o:(.idata$4+0x0): undefined reference to `_nm__allegro_error'
mingw32-make: *** [examples/ex1.exe] Error 1
//

Also, the -g flag is not being passed to the command line during compilation, and it is not added in any of the makefile references to CFLAGS, so none of jpgalleg actually has debugging symbols anyway.

It also looks like the debug version uses -fomit-frame-pointer, doesn't that ruin the stack for debugging purposes?

LoadPng compiled fine, except for the deprecated function warnings for browse.c again. I made a unified diff of the minimum amount of changes necessary to preserve exact functionality and to remove the deprecated function calls. If you use it, you might want to run dtou on it, as it has CRLF line endings. I didn't know which kind of line endings you might want for a diff file.

I've fixed the debug build issues with JPGAlleg.

You can't compile a non-static version of JPGAlleg and link it against static Allegro. That would complicate things and it's useless in general.

I've also made an attempt to fix the issues with building addons on MacOSX. Script allegro-config should be generated in the build dir now, but it's completely untested and I would appreciate if someone could give it a try. Just remember to remove allegro-config from the build dir first (if it is there by any chance).

edit: Oh, and I've applied your patch Edgar. Thanks for all.

So should dynamic library builds always link against other dynamic libraries then? Because to build the dynamic libvorbis libraries I had to hack the build process so that they were linked against the static libogg libraries. I take it this was not correct then? Conversely, if I forced them to link to the dynamic libogg libraries to build the static libvorbis libraries, that would be incorrect also? Perhaps my 'fix' isn't really a sound fix then.

Re: Newest strangesoft snapshot of 4.3.11-r11520 - The .7z file is only 1.0MB, and can't be opened by 7-zip as an archive. The zip file worked fine for me though.

Testing revision 11520 :
Allegro and AllegroGL both compiled fine for all available targets. Logg and LoadPNG built fine as well.

The dynamic versions of JpgAlleg still won't build though. (The makefiles look much cleaner with your latest update BTW).

I'm not sure I know what you're getting at here. So why not link the dynamic JPGAlleg library to dynamic Allegro then? <Doing some research...> Okay, I think I get it. The 'ar' utility doesn't actually create an export library, does it. So wouldn't 'dllwrap' or 'dlltool' be more appropriate to use then?

I guess my main concern is that not all of the addon's build systems mesh perfectly with Allegro's. That is, I think that they should all support the same 6 build options that Allegro does -

make [ "" (Optimized) | DEBUGMODE=1  | PROFILEMODE=1 ] [ "" (Dynamic) | STATICLINK=1 ]

with

make all [ "" (Dynamic) | STATICLINK=1 ]

building all 3 versions of the dynamic or static library, and having the WITH_* defines pass those same options to the individual add on packages.

- even if it is only to say that
"The build of the $(BUILD_TYPE_STRING) $(LIB_NAME_STRING) library is not supported at this time."

Yes, unless you want something else. Then you should change the makefile, which is acceptable.
Just look at what we have here: your_app, allegro, logg, vorbis. Each of the four can be linked as static or dynamic. That makes combinations! Not to mention different build types and there is 4 addons, and some of them have more than one dependency. I don't want that in allegro makefiles. STATICLINK=1 means link all static if possible, if not specified link dynamically, if possible. It is very likely you will have to tune addon's makefile to find the right lib, it's not a big deal. If you don't like it use the binary distro.

Where did it say not to? That works for me. According to that log file you've sent, it works for you too.

Would be nice, but they just don't.

That's fine with me. I never said I wanted to cross breed static and dynamic builds.

But the dynamic build of JpgAlleg isn't working though. The examples don't build in the dynamic version due to undefined references. Here's my latest build log of the four different versions of JpgAlleg (static/dynamic , debugging/optimized) for Revision 11520 :

So the static optimized version, and the static debug version both build fine along with the examples, but then the dynamic optimized and the dynamic debug versions fail to compile the example programs.

All four versions of the library call the 'ar' utility in the same way (pseudocode) :

ar rs LIB_NAME $(OBJ_LIST)

I don't have any dll's in the jpgalleg\lib\mingw32 folder, and I don't think the 'ar' utility creates an export library, so you're really confusing me here.

Edit
I see what's going wrong now. The object files for the example programs are only built for the very first version of the JpgAlleg library that you create. Each time after that, it just links the ex#.o files into the ex#.exe executables without recompiling them first. I had to really scrutinize it to see that. Also, the object files are not being put into the proper folder for their library versions :

//
gcc -c -s -I./include -I../../include -march=pentium -O0 -g2 -Wall -W  -DALLEGRO_STATICLINK -DDEBUG -DDEBUGMODE examples/ex1.c -o obj/mingw32/ex1.o
gcc -s  -L../../lib/mingw32 obj/mingw32/ex1.o -o examples/ex1.exe lib/mingw32/libjpgad_s.a -lalld_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound
//

See how the statically linked version of the ex1 object file gets placed into the obj/mingw32 folder instead of the obj/mingw32/jpgalls folder?

That still doesn't solve the missing dynamic libraries though.

Apparently, JPGAlleg can't be built as a shared lib either. But you can make it link to a shared allegro. The problem here is that make was reusing .obj files from the previous build (where .objs were built with the ALLEGRO_STATICLINK=1 flag). A "make clean" in between would work around it. I've fixed it in SVN now.

Um, actually, none of the addons can be built as a DLL. I like that

EDIT: Yes, it took me an hour to write this post.

You found the necessary changes much faster than I did. I had only gotten through $(EXAMPLE_OBJECTS) and $(EXAMPLES) by the time you had it fixed in SVN.

OT : Now that I've gotten a local working copy of 4.3.11 from SVN, it's so much nicer to just use TortoiseSVN to 'Update' than download it all each time.

Okay, so does that mean that when I want to link my program to allegro dynamically that I link against libjpgad.a and libjpgal.a, and when I want to link my program to allegro statically that I link to libjpgad_s.a and libjpgal_s.a? (Only linking to the appropriate debugging or optimized one of course)

Me too! I'm slow.

Milan, I can test it on osx in a few days when I get a macbook and after I figure out how to use it.

I could do it today or tomorrow if I have time between shopping, skype, work and Allegro 5.

Yes. I'm glad we settled this.

You have to admit though, that it sounds a little strange to have a "dynamic" version of a library that is actually static. Whatever though, I'll get used to it.

Okay, so, all 4 versions of JpgAlleg and the examples build fine for me now. Thank you, Milan.

A while back, I made a thread about adding a mouse_on_screen() function to Allegro here :
Simple Mouse API feature request

I was wondering if it would be alright to have this function added to Allegro. All it does is return a copy of allegro's _mouse_on variable that indicates whether the mouse is on the screen or not, but it's very useful to prevent having two mouse pointers on the screen at the same time when running in windowed mode and you're drawing the mouse pointer yourself. It would also allow other effects such as pausing the game when the mouse goes off the window, and only scrolling when near the edge of the window, but not while off of the window, etc...

Thanks again,
Edgar

The mouse_on_screen() looks good to me. You know what would be nice? If you made a ready-to-apply patch with docs and everything That TortoiseSVN of yours must have a feature of creating diffs.

No, I don't mind making a patch. Does SVN sort out DOS and UNIX line endings automatically?

Do I need to change the .def file? I think that will be taken care of when 'misc/fixdll.sh' is run before the distribution is put together, but I'm not certain.

What format is the documentation supposed to be in? Give me a little while to figure out the _tx stuff, and I'll get back to you.
(Ah, I found 'allegro/docs/src/makedoc/format.txt'. Reading it now.)

Edit

Right Click on local working copy of allegro folder -> TortoiseSVN -> Create Patch. That's handy. The Tortoise UDiff viewer even makes it look nice too.

The diff it made is a little odd though - there were two lines in allegro._tx that had degree symbols changed to an Angstrom and degree symbol. Must be some encoding problem. Since my default save encoding in Code Blocks is UTF-8, I think I changed allegro._tx from Windows-1252 into UTF-8, and so the degree symbol changed. Hold on, let me try again.

Alright, I resaved the files as Windows 1252, and now the patch looks right :
mouse_on_screen patch for
docs\src\allegro._tx
src\mouse.c
include\allegro\mouse.h

Please take a look and see if there's anything that I missed in there.

We keep UNIX line endings in SVN, but it's only important that line endings in the patch are consistent. In yours they are not, but it's not a big deal.

Looks good, I've applied it.

Milan, the OS X build worked fine. I did not remove any config files or do anything out of the ordinary - just the fix.sh, make, install and the lib and addons all compiled and ran without a hitch. Nice!

iMac intel, 10.5.6

Paul

Weird. Sorry about that. The nice thing about Code Blocks is that it displays LF and CRLF line endings the same way, but that's also the reason why I didn't notice it. In the future, I can enable the display of EOL chars in Code Blocks to check first before I submit a patch.

So it looks like the CRLF's were introduced when I created the patch with TortoiseSVN, because the old code context and the new code replacement in the diff were all LF line endings, and just the info about which files it was relating to used CRLF.

Cool, glad to be of service.

I've got a couple other functions related to programmatically finding information on arbitrary graphics driver modes being fullscreen or windowed that I'd like to submit, but I need to go over them again, and create a thread and/or post to them [AD] first. Were you planning on making a release soon for Allegro 4.4 if the MacOS build system checks out?

[AD] would be the the best place to post such things

I would have released it months ago but it's not up to me in the end. Just wanted to nail down this few known issues to make the 4.4 release the most stable ever. If it ever comes out that is. We're all too excited about A5.

It would be also fair to mention it in this thread: DOS is broken in 4.3.10plus and likely will stay so.

I vote Milan for 4.4 branch Tsar.

Since the vote is started, I also vote for a 4.4 public release.

Was the vote about whether to have a 4.4 release, or whether to have Milan be the Tsar? I vote for both in any case