[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