Where is SDL.h located in OS X Distro ?
I think I had asked this question last week and somehow it did not get
answered or maybe my SDL message got marked as SPAM by our stupid e-mail
business/spam rules.
Anyway, I’d like to know where this file lives in the 1.2.7 OSX Distro.
Thanks.
@Mark_WhittemoreWhere is SDL.h located in OS X Distro ?
~/Library/Frameworks/SDL.Framework/Headers/SDL.h
if you installed a recent version of the developer package that works -
otherwise SDL.Framework is empty. I think the package available from
libsdl.org should work now - if not, apply the change I described in
message <pan.2004.04.08.07.54.58.114001 at gmx.ch> (Subject: Re: Mac OS
X development package problems - fixed, Date: Thu, 08 Apr 2004 09:54:58
+0200)
-Christian
Where is SDL.h located in OS X Distro ?
If you’re using Xcode and the SDL framework, it’s in
/Library/Frameworks/SDL.framework/Headers. The compiler will magically
find it when you say “#include <SDL/SDL.h>”, which of course is the
exact opposite of how SDL recommends you include files for
"portability" ("#include “SDL.h”, but do people really install SDL
headers directly into /usr/include these days?). 
If you’re using the BSD packages (e.g. from Fink), then SDL.h will live
somewhere like /sw/include/SDL, and sdl-config exists so autoconf will
automatically find it for you (if you’re using sdl.m4 as found in SDL
source). If you’re planning on using autoconf, you probably shouldn’t
try to use the SDL framework.
-HollisOn Apr 12, 2004, at 8:36 AM, markw at on2.com wrote:
In Unix, the “recommended” way is “SDL.h”, with sdl-config --cflags
adding eg. “-I/usr/include/SDL” to the gcc commandline.
This is ugly and horrible, of course, adding to the collection of trash
that tends to accumulate on compile commandlines. The correct way to do
it is as you say: #include <SDL/SDL.h>, and only add a -I if the SDL
include directory isn’t in the default path (which it usually is), so
most compilations don’t need anything extra at all.
Apparently, some build environments can’t work when <SDL/SDL.h> is included.
I’d much sooner not support those broken environments and force them to find
a localized hack, than to deal with the above mess, though. A fix for brain
damage on one system shouldn’t make building on my system ugly.
YMMV.On Mon, Apr 12, 2004 at 09:33:53AM -0500, Hollis Blanchard wrote:
If you’re using Xcode and the SDL framework, it’s in
/Library/Frameworks/SDL.framework/Headers. The compiler will magically
find it when you say “#include <SDL/SDL.h>”, which of course is the
exact opposite of how SDL recommends you include files for
"portability" ("#include “SDL.h”, but do people really install SDL
headers directly into /usr/include these days?).
–
Glenn Maynard
This is ugly and horrible, of course, adding to the collection of trash
that tends to accumulate on compile commandlines. The correct way to do
it is as you say: #include <SDL/SDL.h>
I think you mean:
#include “SDL/SDL.h”
<> Means use the default include paths (e.g. -I), “” is explicit and
ignores them. I expressly forbid usage of <> in all of my professional
projects and default include paths unless it’s to reference a system
library. It prevents accidentally picking up a stray .h (yes, it happens)
and you know exactly what file you’re including.
–>Neil-------------------------------------------------------------------------------
Neil Bradley "Your mistletoe is no match for my T.O.W. missile!"
Synthcom Systems, Inc. - Santabot - Futurama
ICQ #29402898
Since in the XCode distribution makes SDL a framework, you must use the
<frameworkname/header> notation for including headers from the
framework.
#include <SDL/SDL.h>
or
#include “SDL/SDL.h”
Alternatively, you can just add “/path/to/SDL.framework/Headers” to
your include paths in XCode, and then include “SDL.h” as normal:
#include “SDL.h”
I prefer the latter, if SDL.framework is installed in
/Library/Frameworks because it avoids the problems mentioned. Probably
best not to do it if SDL.framework is installed in the default
~/Library/Frameworks since your XCode project will then only work on
your system.
If you’re using Xcode and the SDL framework, it’s in
/Library/Frameworks/SDL.framework/Headers. The compiler will magically
find it when you say “#include <SDL/SDL.h>”, which of course is the
exact opposite of how SDL recommends you include files for
"portability" ("#include “SDL.h”, but do people really install SDL
headers directly into /usr/include these days?).In Unix, the “recommended” way is “SDL.h”, with
sdl-config --cflags
adding eg. “-I/usr/include/SDL” to the gcc commandline.This is ugly and horrible, of course, adding to the collection of trash
that tends to accumulate on compile commandlines. The correct way to
do
it is as you say: #include <SDL/SDL.h>, and only add a -I if the SDL
include directory isn’t in the default path (which it usually is), so
most compilations don’t need anything extra at all.Apparently, some build environments can’t work when <SDL/SDL.h> is
included.
I’d much sooner not support those broken environments and force them
to find
a localized hack, than to deal with the above mess, though. A fix for
brain
damage on one system shouldn’t make building on my system ugly.
Which build environments are you attempting to use? If you use gcc/g++
and SDL.framework is installed in /Library/Frameworks, then you
shouldn’t have to add anything to compile a file for it to find
SDL.framework, and “-framework SDL” to the gcc flags when you link. If
your build environment somehow doesn’t include /Library/Frameworks in
the default framework search paths, then something is probably wrong.
YMMV.
–
Glenn Maynard
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Jeremy BellOn Apr 12, 2004, at 7:43 PM, Glenn Maynard wrote:
On Mon, Apr 12, 2004 at 09:33:53AM -0500, Hollis Blanchard wrote:
This is ugly and horrible, of course, adding to the collection of
trash
that tends to accumulate on compile commandlines. The correct way to
do
it is as you say: #include <SDL/SDL.h>I think you mean:
#include “SDL/SDL.h”
<> Means use the default include paths (e.g. -I), “” is explicit and
ignores them.
You totally lost me there. The default include paths are what’s there
without any -I arguments. Also, “” does not ignore anything; it just
looks in the current directory before the -I directories (and system
directories). The only difference is that “” looks in cwd first. I
hardly see one being “more explicit” than the other. I also don’t see
what value “SDL/SDL.h” has unless you plan on having the SDL include
directory in your cwd and you want to use that without any -I arguments
(a bit contrived IMHO).
I expressly forbid usage of <> in all of my professional
projects and default include paths unless it’s to reference a system
library. It prevents accidentally picking up a stray .h (yes, it
happens)
and you know exactly what file you’re including.
-I dir
Add the directory dir to the list of directories to be searched for
header files. Directories named by -I are searched before the standard
system include directories.
So even if you have foo/bar.h, /usr/include/bar.h, and -Ifoo in CFLAGS,
you won’t pick up /usr/include/bar.h. I guess you’re talking about the
accidental case where you don’t have -Ifoo in CFLAGS, and that’s fine,
but I still don’t see how “SDL/SDL.h” is better than <SDL/SDL.h>.
Luckily for you, Apple’s gcc/g++ can handle “SDL/SDL.h” in addition to
<SDL/SDL.h>, but I remain baffled by your reasoning. 
-HollisOn Apr 12, 2004, at 7:24 PM, Neil Bradley wrote:
So even if you have foo/bar.h, /usr/include/bar.h, and -Ifoo in CFLAGS,
you won’t pick up /usr/include/bar.h. I guess you’re talking about the
accidental case where you don’t have -Ifoo in CFLAGS, and that’s fine,
but I still don’t see how “SDL/SDL.h” is better than <SDL/SDL.h>.Luckily for you, Apple’s gcc/g++ can handle “SDL/SDL.h” in addition to
<SDL/SDL.h>, but I remain baffled by your reasoning.
Hm… well, I didn’t look at the context before posting - my mistake.
Technically speaking, if it’s in quotes, it’ll look first in the same
location as the module with the #include statement. However, if it’s in
brackets, it’s an implementation defined rule. That might mean scanning
-I or using the INCLUDE environment variable, so in OSX’s case that’s
probably correct.
I’m used to embedded systems (ARM SDT 2.51 to be precise). If I did
"#include “stdio.h”", I’d get a “file not found” error. ;-| I’d need to do
#include <stdio.h>.
–>Neil-------------------------------------------------------------------------------
Neil Bradley "Your mistletoe is no match for my T.O.W. missile!"
Synthcom Systems, Inc. - Santabot - Futurama
ICQ #29402898
Where is SDL.h located in OS X Distro ?
The pkg, of SDL 1.2.7 is kinda f0rked on panther, it does not run a
post install script IIRC. You can run the install scripts in the
package, or just install via source to have SDL.h tossed into your
prefix (/usr/local/include…).On Apr 12, 2004, at 9:36 AM, markw at on2.com wrote:
Coleman Nitroy
@Coleman_Nitroy
nitroy.com/cole
Since in the XCode distribution makes SDL a framework, you must use
the <frameworkname/header> notation for including headers from the
framework.
#include <SDL/SDL.h>
or
#include “SDL/SDL.h”Alternatively, you can just add “/path/to/SDL.framework/Headers” to
your include paths in XCode, and then include “SDL.h” as normal:
#include “SDL.h”I prefer the latter, if SDL.framework is installed in
/Library/Frameworks because it avoids the problems mentioned.
Which problems? Are you saying there are systems/packages which do
not use an “SDL” toplevel directory for the SDL include files? If so,
why don’t they?
-HollisOn Apr 12, 2004, at 8:14 PM, Jeremy Bell wrote:
My assumption was that normally SDL’s header files were installed in
/usr/local/include or some other place where #include <SDL.h> would
work without any other modifications. I haven’t tried this on other
setups, so I gathered this from the comments before, and from SDL
examples which just #include <SDL.h>.
The problem is that on OSX you’d have to #include <SDL/SDL.h> and on
other systems you #include <SDL.h>, so for a multiplatform title you’d
likely have to do something like
#if defined(APPLE)
#include <SDL/SDL.h>
#else
#include <SDL.h>
#endif
which is very ugly. By simply adding SDL.framework’s headers folder to
the header search path of your XCode project (or by adding -I to your
gcc flags if you’re compiling on the command line) you can easily avoid
the above ugliness.
Jeremy BellOn Apr 12, 2004, at 10:59 PM, Hollis Blanchard wrote:
On Apr 12, 2004, at 8:14 PM, Jeremy Bell wrote:
Since in the XCode distribution makes SDL a framework, you must use
the <frameworkname/header> notation for including headers from the
framework.
#include <SDL/SDL.h>
or
#include “SDL/SDL.h”Alternatively, you can just add “/path/to/SDL.framework/Headers” to
your include paths in XCode, and then include “SDL.h” as normal:
#include “SDL.h”I prefer the latter, if SDL.framework is installed in
/Library/Frameworks because it avoids the problems mentioned.Which problems? Are you saying there are systems/packages which do
not use an “SDL” toplevel directory for the SDL include files? If
so, why don’t they?-Hollis
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
The entire point is to use the default include paths.
SDL.h is most commonly installed in /usr/include/SDL/SDL.h; in that case,
#include <SDL/SDL.h> can be used to get it without any additional -I
parameters at all, since it essentially is a system library.
If SDL was installed with “–prefix=/home/glenn/SDL”, then the include
file is in “/home/glenn/SDL/include/SDL/SDL.h”, and the argument would
be “-I/home/glenn/SDL/include”; then the same <SDL/SDL.h> would work.
However, in most cases, no -I is needed at all.
If “SDL/SDL.h” is used, neither /usr/include nor -I will be searched.
(Note that the above is mostly from memory, from what you’ve said, and
from some autoconf docs that had the same issue. I can’t actually verify
it directly, since gcc–the only Unix compiler I have available–treats
#include “” as equivalent to <>, except it first searches the directory
containing the source file. Since this behavior is rather nonstandard,
it’s not very useful for actually testing the above.)On Mon, Apr 12, 2004 at 05:24:59PM -0700, Neil Bradley wrote:
I think you mean:
#include “SDL/SDL.h”
<> Means use the default include paths (e.g. -I), “” is explicit and
ignores them. I expressly forbid usage of <> in all of my professional
projects and default include paths unless it’s to reference a system
library. It prevents accidentally picking up a stray .h (yes, it happens)
and you know exactly what file you’re including.
–
Glenn Maynard
projects and default include paths unless it’s to reference a system
library. It prevents accidentally picking up a stray .h (yes, it happens)
and you know exactly what file you’re including.
The entire point is to use the default include paths.
SDL.h is most commonly installed in /usr/include/SDL/SDL.h; in that case,
#include <SDL/SDL.h> can be used to get it without any additional -I
parameters at all, since it essentially is a system library.
That’s up for some debate, actually. I don’t consider SDL.h a “system
library”, and I’d rather not have my develoers have to install many
different packages in different places when I can include it in my source
tree and have it build right out of the box without having to deal with
directory permissions (many do not have access to /usr/include depending
on your environment). It makes my tree bigger, but it’s a small price to
pay for guaranteeing everyone has the right stuff.
Your mileage and goals may vary, though…
–>Neil-------------------------------------------------------------------------------
Neil Bradley "Your mistletoe is no match for my T.O.W. missile!"
Synthcom Systems, Inc. - Santabot - Futurama
ICQ #29402898
I do this myself in Windows, since I need a few patches, and I used to
do this in Unix back in 1.2.5 for the alpha blit patch.
In that case, if your source tree is foo/src, you could put SDL in
foo/src/SDL/include/SDL/SDL.h, and so on, then add eg.
"-I$srcdir/SDL/include".
In practice, I use sdl-config normally, since it’s not worth breaking from
expected convention (even if I don’t care for the convention :). When I
had a separate SDL build, I had an explicit “-ISDL-1.2.5/include”.On Tue, Apr 13, 2004 at 11:13:58AM -0700, Neil Bradley wrote:
That’s up for some debate, actually. I don’t consider SDL.h a “system
library”, and I’d rather not have my develoers have to install many
different packages in different places when I can include it in my source
tree and have it build right out of the box without having to deal with
directory permissions (many do not have access to /usr/include depending
on your environment). It makes my tree bigger, but it’s a small price to
pay for guaranteeing everyone has the right stuff.
–
Glenn Maynard
Just to be clear: SDL includes are almost always in an SDL subdirectory, eg.
/usr/local/include/SDL, which is normal practice for include sets of more
than one file.
The reason <SDL.h> is normally included instead of <SDL/SDL.h> is that
the generated “sdl-config” script adds the direct SDL path to -I:
02:50pm glenn at zewt/2 [~] sdl-config --cflags
-I/usr/include/SDL -D_REENTRANT
(Actually, I think Sam recommends “SDL.h”; I’m not sure, since both <>
and “” work for me in VC6, VC7 and gcc, which is all of the compilers I use
right now.)
If “<SDL/SDL.h>” makes it much easier for the OSX build environment to
work normally, that’s just one more annoyance of <SDL.h>. :)On Tue, Apr 13, 2004 at 12:07:23PM -0400, Jeremy Bell wrote:
My assumption was that normally SDL’s header files were installed in
/usr/local/include or some other place where #include <SDL.h> would
work without any other modifications. I haven’t tried this on other
setups, so I gathered this from the comments before, and from SDL
examples which just #include <SDL.h>.The problem is that on OSX you’d have to #include <SDL/SDL.h> and on
other systems you #include <SDL.h>, so for a multiplatform title you’d
likely have to do something like
#if defined(APPLE)
#include <SDL/SDL.h>
#else
#include <SDL.h>
#endif
–
Glenn Maynard