The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi All,

Just thought I'd check before trying to do it myself: Has anyone out
there built the SDL 1.2.9 and SDL_mixer 1.2.6 Mac OS X *frameworks*
(not .a's) in universal binary (ppc and i386) form yet?

If so, can someone point me to where I can download them?

Thanks.
__
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

I have built Universal binaries SDL 1.2.9 (out of CVS) and SDL_image
1.2.4 for use with OpenGL. They work just fine. I haven't used any
2D drawing, so I do not know if the SSE blitters are active. I also
haven't tried SDL_mixer.

I also spent quite a bit of time cleaning the cruft out of the
project files left over by several previous projectbuilder/xcode
upgrades. The way I have it set up, the debug configuration builds
for the current target while the release configuration builds for ppc/
i386. SDL_image also required compiling UB versions of libpng and
libjpeg.

I am not prepared to submit these back yet because:
- The install targets (specifically the run_scripts build phases) are
basically flawed. I haven't spent any time trying to update these.
Xcode's existing infrastructure is perfectly capable of dealing with
the install task on it's own, so ideally we would dump the custom
shell scripts entirely, and just use what is already provided to us.

- 10.1/10.2 support. As my project files are set up, the minimum
target that SDL is compiled for is 10.3.9, and requires the 10.4.0
Universal SDK. Xcode 2.2 does contain the ability to compile against
different SDKs depending on the target architecture, so I need to
investigate this. I also don't have any 10.1 or 10.2 systems to test
against. (What is the earliest version that SDL needs to support at
runtime?).

I also haven't come up with a great solution to include paths in
xcode projects (since other users will have these installed at
different locations, or want to install their headers to different
locations). This is the ugly side of using #include "foo" where we
really should be using #include <SDL/foo> (can this please change in
SDL 1.3?).

I assume there is some interest in trying to address these issues and
get SDL building Universal directly out of CVS? How much of this has
already been done by others but not checked in?

Richard

On Jan 5, 2006, at 10:07 PM, Steven Saunders wrote:

Yes, a few of us have been working out the details for this. I think
semi-officially, we support from 10.2. Using the standard options for
the Universal SDK has been introducing additional dependencies which
cause problems for anything less than 10.3.9. There was a problem with
a new dependency with libgcc_s which Apple has fixed in Xcode 2.2/gcc
4.0.1, but there is still a problem with an undefined symbol for
_fprintf$LDBL128 expected to be defined in /usr/lib/libSystem.B.dylib.
We have discovered how to set Xcode to use different versions of gcc
on a per-architecture basis, but I think the libSystem incompatible
version issue is still getting in the way so we are still
investigating the best way to get around this.


Yes, there is a lot of stuff that needs to be cleaned up. It's been on
my todo list. The main SDL project already has undergone some cleanup
which should already be in the 1.2.9 dist, but I haven't gone through
the SDL-satellite projects yet.


I'm not sure what you mean by the install targets being "flawed". But
yes, the shell script phases need to be cleaned up. As I said, the
main SDL project has already undergone some cleanup, but a shell
script phase still exists because we use it to create a package for
distribution. But it is much simpler than before. Among the changes
include, no more spilting a framework into headers and runtime, a .dmg
based package instead of an .pkg installer for privileges concerns,
and a better separation of the core SDL framework and optional
developer stuff.


If you are expecting to use Xcode to actually copy the framework to
/Library/Frameworks using their built-in functionality, it's probably
not going to happen/work because we set the install_name to
@executable_path/../Frameworks which I believe Xcode uses to decide
where to copy things. Furthermore, as I said, we use the script phase
to build us packages for distribution. We don't require or intend
everybody to compile SDL from source just to install it.


In the Xcode field "Header Search Paths", you can specify multiple
locations just by listing them (separated by spaces). I think in our
project templates, we already set the paths to
$(HOME)/Library/Frameworks/SDL.framework/Headers
/Library/Frameworks/SDL.framework/Headers
Add more as needed.


Unforunately, moving to #include <SDL/foo> will never likely work
correctly in a portable sense. Already, not all platforms put their
headers in a directory called SDL/. (For example, FreeBSD Ports puts
theirs in SDL11/.) Furthermore, with Mac frameworks, this will break
down for the SDL-satellite projects. Many distributions put the
SDL_image.h, SDL_mixer.h, etc headers in SDL/, but they are separate
libraries and hence separate frameworks under the Mac. All OS X
framework code would require the usage: #include
<SDL_mixer/SDL_mixer.h> and <SDL_image/SDL_image.h>. Chances are that
most other distros (including OS X based Fink and DarwinPorts) won't
follow this convention. #include "foo" is really the only portable
option unless SDL takes it on themselves to create and enforce
packaging requirements. But I don't think that's going to happen.

-Eric

Not semi-officially: if I tried to ship a game that didn't support 10.2,
my publisher would refuse to ship until I corrected it.

It seems that 10.2 is the minimum acceptable platform in terms of
marketing, at least at this point. I've never had anyone complain that a
title didn't work on 10.1.

I'd actually like it to work back to 10.0, but not if it requires lots
of work or ugly changes...the public beta, though? That crap can go. :)

--ryan.