[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 2009-01-28 at 14:10 -0800, Evert Glebbeek wrote:
> >
> > This is only a syntactic change, the advantages are that it looks
> > better
> > (no macro call required), and that it would be the same on all
> > platforms.
>
> It's the same on all platforms right now too. :P
Yes, but I keep forgetting about it because I find it so ugly, and then
my code won't compile under Windows :P
>
> > The real main function would still be in the .dll/.so as it is now -
> > changing that can wait until later (and would be only an internal
> > change).
>
> So, to be clear on this, the user needs to link to a
> "liballegro_main.a" to get his "proper" main function, right? Not
> linking to that will disable magic main (and breaks Allegro on OS X),
> but it will be automatically included by `allegro-config --libs` on
> *nix (when needed and including OS X) and isn't actually needed
> (anymore) on Windows.
> Do I understand this correctly?
>
Yes, that's the idea (my patch wouldn't do anything like that yet
though). The advantage is, we can procide a .dll/.so which does not have
a main/WinMain() function inside, which just seems messy. A language
binding can the provide its own replacement of liballegro_main.a with
its own main().
Also, OS X should not necessarily break, we just need to document what
you have to do in your own main() besides calling al_main so it will
also work there. Not sure there will be a nice solution so under Windows
and Linux al_main() can be called from the main thread, but from another
thread under OSX. In any case, from a language binding implementor we
could expect more care than from a normal user, so as long as there is a
good way to do it it's likely no big issue.
For me personally the main gain will be getting rid of END_OF_MAIN, it's
one of the things I really hate in A4 :)
--
Elias Pschernig <elias@xxxxxxxxxx>