Re: [AD] Allegro main function in separate library

[Chris Robinson <chris.kcat@xxxxxxxxxx>]

On Monday 25 January 2010 9:05:19 pm Evert Glebbeek wrote:
> This mainly affects OS X.
> The attached file contains an "allegro-main" addon that moves Allegro's
>  magic main to an external library, and the necessary changes to the build
>  scripts. This is necessary in case anyone wants to use bindings to another
>  language from OS X (I don't know about sufficient), or if someone wants to
>  disable Allegro's name mangling. The patch affects the UNIX port in moving
>  umain.c to the addon. This file is normally not used, but there are
>  situations where it might be. The windows port should not be affected. On
>  any platform, a library "liballegro-main-version.so/dylib/a" is compiled
>  but it may be empty, for instance on Windows or UNIX if no magic main is
>  needed.
> 
> Instructions for writing portable code with this addon in place:
>  1. use "int main(int, char **)"
>  2. link against liballegro-main-version in addition to liballegro-version
> 
> Instructions for disabling magic main (when applicable):
>  1. #define ALLEGRO_NO_MAGIC_MAIN to avoid any name mangling
>  2. don't link against liballegro-main-version
>  3. do whatever it is that Allegro requires you to do for it to work in
>  your main function
> 
> This completes the last part of removing END_OF_MAIN() from the main
>  library. It is also in my mind the last missing feature between 4.9 and
>  5.0 as far as the OS X port is concerned (only bug fixing and documenting
>  remain).
> 
> Tested on OS X. Someone please confirm that this indeed does nothing in
>  other cases. The iPhone port should probably be changed as well.

I have to wonder why Allegro's still even using main mangling. To me, the idea 
of getting rid of END_OF_MAIN() was to get rid of the hacks that the lib used 
to get things running properly at startup, which was in turn caused by the 
DOS-centric design of 3.x that didn't carry well into the Windows/Linux/Mac 
ports, along with the bid to retain API compatibility, for 4.x.

The 5.0 API is a clean break from that, and represents a way to completely 
avoid the design decisions that resulted in the need for the magic main stuff. 
I'd much rather have an explicit END_OF_MAIN or even a clever al_main macro, 
than hidden alterations to the standard main() routine that you need to opt 
out of. But personally, I think the design of the API should work so that 
overriding the main entry point isn't needed in the first place.