Re: [AD] Preparing for 4.9.9

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Mon, 2009-03-09 at 17:20 -0700, Evert Glebbeek wrote:
> On 9 mrt 2009, at 17:17, Peter Wang wrote:
> > Apart from the problem with ex_pixelformat, is there anything that
> > needs to be resolved before another WIP release, say, in the next
> > couple of weeks?
> 
> I don't think so, but I'd like to try the pkg-config support on OS X.
> 

I'd really like to fix END_OF_MAIN. I can update my old patch if that's
the solution we want (basically, copy SDL behavior, except do not
redefine "main" but instead require programs to define an "al_main"). I
could also make it so a fixed "int main(int argc, char **argv)"
prototype is expected like with SDL by simple adding:

#define main al_main

However, as Allegro programs are not normal C programs - under Windows,
they really use WinMain() and not main(), and under OSX the "main"
function just is a user thread function) - I think *not* naming the
function "main" actually is the better thing to do. Why make users
believe they use main() when they don't.

About the arguments of the function, it's not possible to allow "int
al_main(int argc, char **argv)" as well as "int al_main(void)". So we'd
have to choose one.

As I said in the past, sticking a completely out-of-place looking macro
at the end of the functions seems to be a much more horrible thing to do
to me. While the upper part of the function in A4 looks like the normal
C main() - as a whole it makes programs look much less like normal C
code than if simply using al_main() and no macro.

Independent of if we define the user's main the A4 way or the SDL way or
without any #define magic, we probably also should adopt the way how SDL
does not define the real main inside of the .dll/.so, but in a separate
small library. This can be done later though, as far as I understand
it's mainly important for library wrappers who want to access
the .dll/.so and might not like a "main" symbol in there.

-- 
Elias Pschernig <elias@xxxxxxxxxx>