I just downloaded the Mac OSX version of SDL-1.2.8. There does not seem
to be an “SDL.h” file.
I just downloaded the Mac OSX version of SDL-1.2.8. There does not
seem to be an “SDL.h” file.
Sure there is, it’s in /Library/Frameworks/SDL.framework/Headers
Apple’s gcc will find it automatically if you reference it as <SDL/
SDL.h>
-bobOn Jun 9, 2005, at 8:28 PM, Patrick Connors wrote:
Quoth Bob Ippolito , on 2005-06-09 21:39:41 -0700:
Apple’s gcc will find it automatically if you reference it as <SDL/
SDL.h>
Don’t do that. See
http://www.libsdl.org/cgi/docwiki.cgi/FAQ_20Including_20SDL_20Headers.
If the statement
#include “SDL.h”
doesn’t find the appropriate file, your build environment is
misconfigured.
-bob
—> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050610/a8b8e29e/attachment.pgp
Whenever you install SDL onto a unix/linux system, it typically
installs the SDL header files such that they are not directly available
for inclusion. They are put in a folder usually called SDL, usually
within your current include path. Technically in this usual situation,
you could include SDL.h by including SDL/SDL.h as someone else had
suggested. However then, obviously your program won’t build on some
systems without making changes (to wit, if you install the SDL
frameworks, you cannot build most SDL software without making changes,
because SDL files have different locations on Mac OS X.) SDL has taken
a more explicit route to help guarantee results. That is, when
installing SDL, a shell script called “sdl-config” is also installed.
You execute this program during your configuration or build phase, and
it will return compiler and linker flags which tell your compiler and
linker where to find SDL headers and libraries. For instance:
$ sdl-config --cflags
-I/opt/local/include/SDL -DTHREAD_SAFE
$ sdl-config --libs
-L/opt/local/lib -lSDL
(Note: you may have noticed -DTHREAD_SAFE, that is the compiler’s
command-line option to define a C/C++ preprocessor macro, this is the
second advantage of using a build-process configuration program.)
sdl-config will spit out different values on different systems. It all
depends on where the headers and libraries were installed on the system
in question. The above printout is applicable to having installed SDL
from Darwin Ports (darwinports.opendarwin.org.) This doesn’t really
apply to XCode, because XCode makes you create a “project” to get this
information. Mac OS X is a unix system, but they have augmented the
standard way of searching for header-file inclusions, and linking. The
underlying unix way of doing things is still there, but if you
installed the SDL framework, then the unix-typical method of invoking
sdl-config won’t work (although, it doesn’t appear that you tried to
invoke sdl-config, otherwise that would probably be the problem you’re
reporting; it is likely then that you wrote your own SDL test app and
when that didn’t work you sent the bug complaint; don’t ever make any
assumptions that something going wrong is NOT your fault, you SHOULD
have downloaded someone else’s SDL app and tried building it before
reporting the problem as a bug.)
However, recently my hard drive broke on my ibook, and when I
reinstalled SDL on my new system, I used the frameworks as you probably
have, because I wanted to be able to distribute Mac OS X binaries of my
software. So I wrote my own sdl-config script. It’s a bit crude, and I
hope to hear some people offer adjustments to it, but in its present
form it gets the job done. Typically I invoke a command-line like this
to build my SDL software:
cc sdl-config --cflags -c source1.c
cc sdl-config --libs source1.o source2.o -o program
One last thing, if you don’t know about linking to SDLmain: google. I’d
type it here but I have to get going. Finally, here is my SDL config
script:
#!/bin/sh
for param in $@
do if [ “$param” = “–cflags” ]
then echo -DTHREAD_SAFE -I/Library/Frameworks/SDL.framework/Headers
-I/Library/Frameworks/SDL_image.framework/Headers
-I/Library/Frameworks/SDL_mixer.framework/Headers
-I/Library/Frameworks/SDL_net.framework/Headers
-I/Library/Frameworks/SDL_console.framework/Headers
else if [ “$param” = “–libs” ]
then echo -framework SDL -framework OpenGL -lobjc -framework Cocoa
-framework QuickTime /Users/donny/SDL-1.2.8/src/main/libSDLmain.a
else if [ “$param” = “–version” ]
then echo 1.2.8
fi
fi
fi
done
Donny Viszneki wrote:
However, recently my hard drive broke on my ibook, and when I
reinstalled SDL on my new system, I used the frameworks as you probably
have, because I wanted to be able to distribute Mac OS X binaries of my
software. So I wrote my own sdl-config script. It’s a bit crude, and I
hope to hear some people offer adjustments to it, but in its present
form it gets the job done. Typically I invoke a command-line like this
to build my SDL software:cc
sdl-config --cflags-c source1.c
ccsdl-config --libssource1.o source2.o -o program
I think the SDL installer for Mac OS X should include
both “sdl-config” as well as “libSDLmain.a”, instead of
just providing Xcode templates and the source files…
It should be possible to use SDL.framework, without Xcode ?
Especially since it needs the non-standard -I flag, and
breaks if you try to include the framework headers directly,
with something like: “#include <SDL_image/SDL_image.h>”…
(Not saying that SDL needs to adopt to any Mac-standards but…
that <SDL/SDL.h> works the same on both systems is pure luck,
for another example see: <GL/gl.h> versus <OpenGL/gl.h> ?)
Since Apple has hacked their GCC to do framework-style paths,
while the others just use directories. (both break on Mac OS 9,
which thinks that the header filename involved is “SDL/SDL.h”)
It might also be needed to bring back the “Runtime” (user)
version of the frameworks, since removing the Headers/ and
stripping the shared libraries of the debugging symbols (-S)
saves several hundred KB (!) - which matters since frameworks
will be copied to the Frameworks folder inside the .app bundle.
(The runtime frameworks should be bundled with the application)
And it shouldn’t install the developer frameworks to ~/Libraries
either, since Xcode isn’t smart enough to recognize such paths
but expands it to e.g. “/Users/afb” - which of course then breaks
on all other machines when trying to open up the project file…
So the best approach is to install devel under /Library/Frameworks,
and just use ~/Library/Frameworks as a fallback for unprivileged ?
I will offer improved installers for SDL on Mac OS 9 / Mac OS X,
as part of the SpriteWorld X project. (http://spriteworldx.sf.net)
Where “OS 9” mostly means CFM, and “OS X” mostly means Mach-O.
The CFM runs fine on OS X too, and the Mach-O could be Darwin…
–anders
Thanks, guys.
I searched the entire machine - No SDL.h. No framework, either. Oops. I
probably downloaded the framework incorrectly. Will try again, keeping
all of your excellent replies in mind. Gotta fly; dinner date.
- Patrick> 2. Mac OSX Bug: Where’s “SDL.h”? (Patrick Connors)
- Re: Mac OSX Bug: Where’s “SDL.h”? (Bob Ippolito)
- Re: Mac OSX Bug: Where’s “SDL.h”? (Drake Wilson)
- Re: Mac OSX Bug: Where’s “SDL.h”? (Donny Viszneki)
- Re: Mac OSX Bug: Where’s “SDL.h”? (Anders F Bj?rklund)
Message: 2
Date: Thu, 9 Jun 2005 20:28:14 -0700
From: Patrick Connors <@Patrick_Connors>
Subject: [SDL] Mac OSX Bug: Where’s “SDL.h”?
To: sdl at libsdl.org
Message-ID: <65088f8dbc17076c0899bb01fce0d630 at patrickconnors.org>
Content-Type: text/plain; charset=US-ASCII; format=flowedI just downloaded the Mac OSX version of SDL-1.2.8. There does not seem
to be an “SDL.h” file.
So the best approach is to install devel under /Library/Frameworks,
and just use ~/Library/Frameworks as a fallback for unprivileged ?
Isn’t that what it already does?On Jun 10, 2005, at 9:35 AM, Anders F Bj?rklund wrote: