[SDL] Graphics/Audio Driver selection at runtime
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
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"
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
> 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")
Package B: ("framework")
/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