This was a distinction between using a .dylib distribution of SDL vs.
the .framework distribution. Back in the 1.2 days, some platforms
needed a special piece of code to redefine/override main(). Mac was
one of these platforms. Some distributions included an additional
SDLmain static library that provided this. But this was a pain in butt
for the SDL.framework distribution (and SDLmain had other various
complications thanks to all the crazy hoops Apple makes us jump
through for Xcode, Universal Binaries, changing compilers, user
directories and permissions, etc.). Also, on Mac, there were at least
3 variations on how to provide SDLmain with slightly different
capabilities, so rather imposing the decision of which one to use, the
users of the framework were expected to include the version of
SDLmain.m they wanted with their source and compile it in. (We used to
have nice Xcode templates which let you pick what kind of Mac/SDL
project and it automatically generated the correct SDLmain.m for your
project. (Too bad Apple nerfed the Xcode the template system so 3rd
parties can’t really utilize it effectively.)
That CMake module was given the knowledge about this, so if the
.framework version was being used, you were expected to compile in a
SDLmain.m with your project.
Anyway, SDLmain is finally gone for SDL 2. But the CMake module has
not been updated for 2. I actually recommend a new CMake module be
written for SDL 2. (There are some weird things going on in that
module and there are some corner case bugs in there, but they were not
changed to not break compatibility. We get a clean slate with SDL 2.)
-EricOn 11/20/12, Vittorio Giovara <vitto.giova at yahoo.it> wrote:
Hi,
I was studying the FindSDL.cmake module that is being shipped with a recent
cmake and I can’t understand this section:
IF(NOT SDL_BUILDING_LIBRARY)
IF(NOT ${SDL_INCLUDE_DIR} MATCHES “.framework”)
# Non-OS X framework versions expect you to also dynamically link to
# SDLmain. This is mainly for Windows and OS X. Other (Unix) platforms
# seem to provide SDLmain for compatibility even though they don’t
# necessarily need it.
[cut]
ENDIF(NOT ${SDL_INCLUDE_DIR} MATCHES “.framework”)
ENDIF(NOT SDL_BUILDING_LIBRARY)
If I understand correctly, the comment can be interpreted as “When using
SDL as library as Windows and on OS X you need to provide SDLmain in some
way too; if you are on OSX and using SDL as framework, you don’t need to do
so”. Maybe the comment could be rewritten for some improved clarity, but
what I’m wondering about is the second part of the statement: in fact in my
application even if I link SDL.framework (and not a shared library) it is
required that I link SDLMain too. or i get a nice
NSInternalInconsistencyException when creating the window.
Maybe the fact that my application is written in Pascal is preventing the
framework to set the entry point correctly, but if anyone could shed some
light on this matter I’d be grateful the same.
–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/