[SDL] Graphics/Audio Driver selection at runtime

Steven Johnson SDL at sakuraindustries.com
Wed Sep 14 23:30:02 PDT 2005

Andras Salamon wrote:

> Copying what the JavaVM framework does is not that useful.  To minimize
> yet more special hacks for Mac OS X, a solution that fits into the
> existing autotools macros seems best.

Unless I missed something, you can't even *build* the SDL.framework
with the autotools/configure - only with the three Xcode projects ?

i.e. autotools works OK, just that it builds a dylib instead -
      and installs everything in the bin/include/lib/man dirs.

"Mostly" OK, anyway, just ran into some silly bug with the default
glibtool version (1.5) on Tiger, when building as fat binaries...

> Looking at the existing support in sdl.m4, there are the --prefix,
> --with-sdl-prefix and --with-sdl-exec-prefix options to configure.

I'm not sure what kind of effort it'll take to teach autotools 
frameworks ?
I was only talking about a simple packaging solution, not more 

But if someone wants to it more thoroughly, then - by all means - do 
(but hardcoding /bin/ like that, seems that they don't *want* it 

Seems easier to me to just do a symbolic link, from the "usual" 
$PREFIX/bin/ ?
But I just gave up on using autocrud to configure SDL/OpenGL, I must 

>> I know that Apple/NeXT designed the frameworks to bundle everything
>> into one place, but there is *no* reason for them requiring that
>> everyone else adopt to their lefthanded ways of doing things, always.
> Agreed.  At last count I had five separate versions of the SDL and
> associated frameworks scattered across my filesystem, and that was
> just the copies bundled with apps that use SDL.  If people want to use
> frameworks in this way, it would seem to make more sense just to 
> abandon
> the whole dynamic linking enterprise and go back to static linking.

Now we are talking about different things. You are *supposed* to copy
all the frameworks to each and and every application - so that they
are self-contained and become drag-and-dropable through the Finder...

If that's how *they* want to play it, fine. But it doesn't mean it's
a very portable solution, nor that it sets a goal for everyone else...
I just wanted the framework version of SDL to support "sdl-config" too.

Then Apple can continue with their Frameworks instead of include/lib,
and you can choose which method you want to use by using different
SDL installations: (that each come with a different sdl-config script)

Package A: ("library")
Optional A:

Package B: ("framework")
Optional B:
/Developer/ProjectBuilder\ Extras [PB]
/Library/Application\ Support/Apple/Developer\ Tools [Xcode]

Then you can choose whether you want to use A) or B),
where A) would be provided through DarwinPorts/Fink...

But, even if you do use the alternate B) method provided by
the suggested PKG installer - you *still* get a sdl-config.

It's just being located in a pretty weirdo-looking $PATH.

And if you add that when building, your Makefile can look like:
SDL_CFLAGS = $(shell sdl-config --cflags) -DHAVE_SDL_IMAGE
SDL_LIBS = $(shell sdl-config --libs) -lSDL_image

And you can still use the framework, instead of the library ?

>> I'm staying clear of ~/Library/Frameworks for all future, since
>> Xcode just hates relative paths and replaced it with /Users/afb...
>> Not exactly portable, or even movable to another developer machine ?
> I thought Xcode could use $HOME to avoid relative paths?

I haven't checked again with Xcode 2.1 or 2.2, but at
least 1.5 and 2.0 just hated that in the file list.

I usually end up hacking the XML directly, to change it.
(find/replace is a lot faster than doing it in the GUI)


More information about the SDL mailing list