SDL_image/SDL_image.h framework problem

SDL Development
#1

hello, i am following lazyfoo’s instructions on SDL development and i added
the file SDL_image.framework to /Library/Frameworks and when i
am in xcode and go to add>existing framework>SDL_image.framework> add. and
then run the code it says error: SDL_image/SDL_image.h: No such file or directory.

why didn’t it find the header since i included the framework?? im very
confused, please help :slight_smile: thank you very very much–
View this message in context: http://old.nabble.com/SDL_image-SDL_image.h-framework-problem-tp32281659p32281659.html
Sent from the SDL mailing list archive at Nabble.com.

#2

Verify SDL_image.h is inside the framework (SDL_image.framework/Headers).

Either you need to make sure your #includes look like
#include <SDL_image/SDL_image.h> // not portable
or
#include “SDL_image.h” // portable, but you must add
/Library/Frameworks/SDL_image.framework/Headers to your project’s
Header Search Paths.

-EricOn 8/17/11, NOmNOmNOm wrote:

hello, i am following lazyfoo’s instructions on SDL development and i added
the file SDL_image.framework to /Library/Frameworks and when i
am in xcode and go to add>existing framework>SDL_image.framework> add. and
then run the code it says error: SDL_image/SDL_image.h: No such file or directory.

why didn’t it find the header since i included the framework?? im very
confused, please help :slight_smile: thank you very very much

View this message in context:
http://old.nabble.com/SDL_image-SDL_image.h-framework-problem-tp32281659p32281659.html
Sent from the SDL mailing list archive at Nabble.com.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

#3

Hi Eric,

Why would one be less portable than the other?
#include <SDL_image/SDL_image.h>
#include "SDL_image.h"
In fact, on MacOS, the second is more trouble. On other platforms
it hardly makes any difference.

And why keeps the quoted version popping up?
The notation with quotes is meant to be used for include
files of a project. The compiler will first start to look in
the directory of the current source file.
If it can’t be found, then the compiler will search the
list of INCDIRs (default and -I).

The notation with the angle brackets is typically used for
include files outside the project. Either it is on the
default list of directories (INCDIRs), or you specify it on the
compiler command line (-I). (In Xcode “Header Search Paths”.)

There is an advantage of using <SDL_image/SDL_image.h>
Compilers on MacOS have an extra trick. If you specify
framework search directories (-framework) then the
#include <SDL_image/SDL_image.h>
has the advantage that you do not have to list anything
in the “Header Search Paths”.
Oh, and on Linux if SDL_image.h is installed in /usr/include/SDL_image
then you don’t have to add a -I option either. On the other
hand, if you include “SDL_image.h” then you must add
-I/usr/include/SDL_image
(I know, in real life it is installed /usr/include/SDL, but
that’s another story.)
– Kees

Op 2011-08-17 20:57 , Eric Wing schreef:> Verify SDL_image.h is inside the framework (SDL_image.framework/Headers).

Either you need to make sure your #includes look like
#include<SDL_image/SDL_image.h> // not portable
or
#include “SDL_image.h” // portable, but you must add
/Library/Frameworks/SDL_image.framework/Headers to your project’s
Header Search Paths.

-Eric

On 8/17/11, NOmNOmNOm wrote:

hello, i am following lazyfoo’s instructions on SDL development and i added
the file SDL_image.framework to /Library/Frameworks and when i
am in xcode and go to add>existing framework>SDL_image.framework> add. and
then run the code it says error: SDL_image/SDL_image.h: No such file or directory.

why didn’t it find the header since i included the framework?? im very
confused, please help :slight_smile: thank you very very much

View this message in context:
http://old.nabble.com/SDL_image-SDL_image.h-framework-problem-tp32281659p32281659.html
Sent from the SDL mailing list archive at Nabble.com.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#4

Hi Eric,

Why would one be less portable than the other?
#include <SDL_image/SDL_image.h>
#include "SDL_image.h"
In fact, on MacOS, the second is more trouble. On other platforms
it hardly makes any difference.

Because many package systems that for example you find on Linux will
put SDL_image under <SDL/SDL_image.h>, not <SDL_image/SDL_image.h>.
Package maintainers have total discretion over where they install
components. We don’t have any control over this, nor should we dictate
to a platform/package system how to do their job. (We can give
guidelines, but package maintainers are going to know their trade
better than we do, and if they need exceptions we’re not aware of, so
be it.)

And why keeps the quoted version popping up?
Simple answer: quotes are for user headers, angle brackets are for
system headers. SDL is not technically a system header. Milage will
vary by compiler and installation configuration how much of a pain
this will be if you use the wrong one.
(Trivia: There was a really bad bug under Project Builder/gcc on OS X
10.0-10.2 (or .3) where it was ultra sensitive to quotes/brackets and
if you used paths.)

There is an advantage of using <SDL_image/SDL_image.h>
Compilers on MacOS have an extra trick. If you specify
framework search directories (-framework) then the
#include <SDL_image/SDL_image.h>
has the advantage that you do not have to list anything
in the “Header Search Paths”.

Yes, I am fully aware of this, as I’ve been the unofficial OS X
package maintainer for many years now. As much as I like this
convenience on OS X, as I said, this is not portable.

Oh, and on Linux if SDL_image.h is installed in /usr/include/SDL_image
then you don’t have to add a -I option either. On the other
hand, if you include “SDL_image.h” then you must add
-I/usr/include/SDL_image
(I know, in real life it is installed /usr/include/SDL, but
that’s another story.)

No, that isn’t another story. That is the heart of this story.

It might be
/usr/include/SDL
or
/usr/include

FreeBSD at one time put SDL 1.2 under
/usr/local/include/SDL11 (yes, that’s 11)

-EricOn 8/17/11, Kees Bakker <kees.bakker at xs4all.nl> wrote:

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

#5

Op 2011-08-17 22:37 , Eric Wing schreef:

Hi Eric,

Why would one be less portable than the other?
#include<SDL_image/SDL_image.h>
#include "SDL_image.h"
In fact, on MacOS, the second is more trouble. On other platforms
it hardly makes any difference.
I guess we’ll never agree on this. But I see two issues here.
One is the usage of “SDL.h” instead of <SDL.h> and the
other issue is the extra directory in the filename.
Because many package systems that for example you find on Linux will
put SDL_image under<SDL/SDL_image.h>, not<SDL_image/SDL_image.h>.
Well, it’s not so much the package maintainer. We do it ourselves.
The configure of SDL_image does it. And if you ask me, the package
maintainers simply follow that.
Package maintainers have total discretion over where they install
components. We don’t have any control over this, nor should we dictate
to a platform/package system how to do their job. (We can give
guidelines, but package maintainers are going to know their trade
better than we do, and if they need exceptions we’re not aware of, so
be it.)

And why keeps the quoted version popping up?
Simple answer: quotes are for user headers, angle brackets are for
system headers. SDL is not technically a system header.
But the point is: use quotes for your own program and angle bracket
for include file that lives outside your project.
Milage will
vary by compiler and installation configuration how much of a pain
this will be if you use the wrong one.
(Trivia: There was a really bad bug under Project Builder/gcc on OS X
10.0-10.2 (or .3) where it was ultra sensitive to quotes/brackets and
if you used paths.)
So? Should we all be afraid of angle brackets because someone
on OSX screwed up?

There is an advantage of using<SDL_image/SDL_image.h>
Compilers on MacOS have an extra trick. If you specify
framework search directories (-framework) then the
#include<SDL_image/SDL_image.h>
has the advantage that you do not have to list anything
in the “Header Search Paths”.
Yes, I am fully aware of this, as I’ve been the unofficial OS X
package maintainer for many years now. As much as I like this
convenience on OS X, as I said, this is not portable.
Like I said above, we’ll probably never agree then.

But what if someone accidentally copies SDL.h inside the
project tree. Using “SDL.h” the program builds fine. But
is that what we want? Does that local copy of SDL.h match
up with the library installed on the system? Maybe, maybe not.
With <SDL.h> it would use the correct version
of SDL.h

Oh, and on Linux if SDL_image.h is installed in /usr/include/SDL_image
then you don’t have to add a -I option either. On the other
hand, if you include “SDL_image.h” then you must add
-I/usr/include/SDL_image
(I know, in real life it is installed /usr/include/SDL, but
that’s another story.)
No, that isn’t another story. That is the heart of this story.

It might be
/usr/include/SDL
or
/usr/include

FreeBSD at one time put SDL 1.2 under
/usr/local/include/SDL11 (yes, that’s 11)
OK, that’s an interesting one. I have no solution for that. FreeBSD
screwed up and we’re all doomed :slight_smile:
– Kees> On 8/17/11, Kees Bakker<@Kees_Bakker> wrote:

#6

Well, it’s not so much the package maintainer. We do it ourselves.

It depends if you are in an organization/institution.

The configure of SDL_image does it. And if you ask me, the package
maintainers simply follow that.

configure is 3rd issue. Not all systems support configure. configure
itself is also fragile. It is terrible that it depends on executing a
process. It doesn’t handle multiple installations of SDL well. And it
is generally oblivious to cross-compiling issues.

The emphasis currently in SDL is geared towards maximum portability,
so reliance on configure is avoided.

So? Should we all be afraid of angle brackets because someone
on OSX screwed up?

It was an example to show that portability goes beyond things you
might currently know about.

But what if someone accidentally copies SDL.h inside the
project tree. Using “SDL.h” the program builds fine. But
is that what we want? Does that local copy of SDL.h match
up with the library installed on the system? Maybe, maybe not.
With <SDL.h> it would use the correct version
of SDL.h

Actually, local copies are better. Again, in an institution like a
school where students don’t get root access on the school’s computers
to update an ancient 3+ year package installation (think Debian), they
may need build against a local copy of SDL. (Also think SDL 1.2 vs
1.3.)

But I don’t even need to go there. Again, by definition, SDL is not a
system header.

FreeBSD at one time put SDL 1.2 under
/usr/local/include/SDL11 (yes, that’s 11)
OK, that’s an interesting one. I have no solution for that. FreeBSD
screwed up and we’re all doomed :slight_smile:

Current SDL doesn’t care. That’s the beauty of what we currently have
and have achieved.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/