[SDL] OS X help [Frameworks & SDL_image]
David Leimbach
leimbacd at bellsouth.net
Sun Feb 24 07:01:01 PST 2002
On Sunday, February 24, 2002, at 07:34 AM, Max Horn wrote:
> At 1:38 Uhr +0000 24.02.2002, Dominique Louis wrote:
>> Hi Darrell or any other MacOS developer,
>> Just as a matter of interest what is the MacOS equivalent of the
>> Dynamic Linked Library or Shared Object for SDL called?
>> Does it have a particular filename extentions like under Windows and
>> Linux?
>
> If you talk about OS X, the extension for a "shared library" is .dylib.
> The extension for a "loadable module" is usually .so (though nothing
> forces you to use that, just a convention. That's the core, and what
> the automake based build system of SDL creates on MacOS X (.dylibs that
> is).
>
I only ever get static to work so I never see dylibs come out of the
automake based SDL build on OS X. Is this different in CVS? [I need to
reverify this but I distinctly remember wanting to use frameworks as a
result of failed attempts to build a shared library of the following:
SDL and SDL_image].
>
> The high-level bretheren of these are Frameworks (.framework, shared
> library, but can include multiple versions, meta-data, header files,
> resources like images, documentation etc.), and Plugin Bundles (.bundle
> usually, but can be anything; again, this can contain additional data).
> The Project Builder based build system of SDL creates Frameworks.
>
This Framework idea is really exciting IMHO. Header files and libs all
in one place. The framework itself can be thought of as a directory of
all the stuff you need for the framework contained in one place. In
fact it exists as a directory on disk much like Cocoa apps are
directories on disk with a binary hidden in a deeper subdirectory.
In the gui frameworks show up as directories while *.app's show up as
"files". These files are really directories on disk but the command
line "open" can run these special directories as if you had double
clicked them in the GUI. ["openapp" in GNUstep for you linux/Unix
non-OSX fans can do the same thing provided your GNUstep environment is
up and running/]
> Hm, AFAIK the chance to see Kylix on OS X are pretty slim, especially
> in a state where it is usable to produce "real" MacOS X apps (i.e.
> giving you access more than just the core BSD APIs). Do you have any
> reason to believe differently? I'm just curious.
>
I think Max is correct unless someone has an inside information we
don't. The ability to use Cocoa will require objective-c and frameworks
support [maybe it can be done with Cocoa's other native language -
java]. If you aren't using Cocoa you are using Carbon to code for
Aqua. Cocoa is, by things I have read on apple's site, going to be only
API of the two that they continue to support and develop in the long
term. Carbon is there to get your app to OS X quickly while you work on
Cocoa-ifying it as far as I can see.
Now I suppose you could write Kylix to use QT on OS X but even QT uses
Carbon and then you are simply adding another layer of
Kylix->C++->QT->Carbon->Quartz. So Kylix doesn't seem a likely
candidate for OSX unless they wrap up the whole Carbon or Cocoa API in
Kylix [pascal-like] code [this is presuming that Kylix needs a special
ABI to call on Cocoa/Carbon functions].
Blah... this all has nothing to do with SDL directly.
>
> Max
> -- -----------------------------------------------
> Max Horn
> Software Developer
>
> email: <mailto:max at quendi.de>
> phone: (+49) 6151-494890
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
>
More information about the SDL
mailing list