| Re: [AD] Preparing for 4.9.9 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 9 mrt 2009, at 18:06, Elias Pschernig wrote:
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.
Ah, right. Yes, I'll look at that too (again, I think... or at least
again that I say I will).
However, as Allegro programs are not normal C programs - under
Windows,
they really use WinMain() and not main(),
I think there's a patch to change this?
and under OSX the "main"
function just is a user thread function)
It still uses a regular main() though ;)
- 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.
We can argue over that if you like. :)
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.
There's probably an obvious reason why this has to be so, but I can't
say I see what it is specifically: if you #define main allegro_main,
and then in the file that has the actual main() you "extern void
allegro_main(int, char **)", what exactly goes wrong?
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.
Again, we can argue about this. At best though, they are equally un-C
like in that neither of those looks like a normal C program.
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.
Yes, we definitely should. That'll only affect OS X though, right?
Evert