VS: Re: SDL and kdevelop

----original----

gcc -DHAVE_CONFIG_H -I. -I. -I… -O0 -g3 -Wall -c main.c
main.c:32: SDL.h: No such file or directory
make[3]: *** [main.o] Error 1

This just looks like a bad “#include” path, go:
$ sdl-config --libs

which outputs the command line parameters to send gcc. Kdevelop is wonk,
because you can’t easily tell it to just use that or to run sdl-config as
part of your configure script, so you have to take any parameters that
start with an -L or a -l and put them in “Project Options|Linker Options|
additional libraries”. Take any other parameters and put them in “Project
Options|Linker Options|additional flags”
----end original----

Actually, sdl-config --libs outputs linker options. sdl-config --cflags
outputs the include dirs. And those must be set to something that says
include dirs or whatsoever (haven’t even seen kdevelop, can’t say
precisely), not the library thingie setting. It’s the includes that are
wrong, not the libraries. There might be some error at the linking phase
though, if the libraries are not set correctly. To work around that, follow
SmokeSerpent’s instructions.

Petri Latvala

Someone needs to go back and redo the “using SDL with KDevelop” doc, as it’s
/really/ outdated. (Not that I’m volunteering myself, or anything :wink:

Basically the problem here is likely an include one (either with #include in
the code, or with the include paths in the gcc command line.) So both of the
previous posts could be right :wink:

Without actually seeing the project, I couldn’t say specifically where it would
be. Could the original poster post their entire project as-is somewhere online
so we could look at their KDevelop configuration?

Also, on a side note, in spite of the fact that many people report problems
using SDL with KDevelop (myself included, a while ago), SDL apps can be created
and managed quite nicely in KDevelop. You just have to do a series of little
raindances to get them to play nice together :wink: Tux Typing has been managed in
KDevelop, and my newer projects (Nodin Grand, et al) will be using KDevelop as
well.

In a nutshell, here’s some of the things you need to keep in mind when making
an SDL app in KDevelop:

  1. When you create the project, unless you /really/ know what you are doing,
    just create a “Terminal C/C++” or “custom” project. This will prevent an awful
    lot of configure script headaches.

  2. In the “Project Options” dialog, under “Linker Options” be certain to see
    the additional flags setting tp “$(shell sdl-config --cflags) $(shell
    sdl-config --libs)”

  3. Enter any additional flags/libraries in “additional libraries” (for example,
    if you are using SDL_Mixer, SDL_Image, etc, add them thusly “-ISDL_mixer
    -ISDL_image … etc.”)

Currently, I think you can pretty much kiss SDL lib checking in the configure
script goodbye. This sucks, I know, but until KDevelop allows us to modify this
script ourselves (or enter additional junk for it) you are stuck. Now, you can
get around this by creating a “custom” project (allowing you to create all the
configure and makefile stuff yourself), or by changing the permissions on
configure to not allow KDevelop to monkey with it. But neither are very good
options if you are like me and have yet to figure out the intricacies of
automake/autoconf ;-)On Wed, 09 May 2001, you wrote:

----original----

gcc -DHAVE_CONFIG_H -I. -I. -I… -O0 -g3 -Wall -c main.c
main.c:32: SDL.h: No such file or directory
make[3]: *** [main.o] Error 1

This just looks like a bad “#include” path, go:
$ sdl-config --libs

which outputs the command line parameters to send gcc. Kdevelop is wonk,
because you can’t easily tell it to just use that or to run sdl-config as
part of your configure script, so you have to take any parameters that
start with an -L or a -l and put them in “Project Options|Linker Options|
additional libraries”. Take any other parameters and put them in “Project
Options|Linker Options|additional flags”
----end original----

Actually, sdl-config --libs outputs linker options. sdl-config --cflags
outputs the include dirs. And those must be set to something that says
include dirs or whatsoever (haven’t even seen kdevelop, can’t say
precisely), not the library thingie setting. It’s the includes that are
wrong, not the libraries. There might be some error at the linking phase
though, if the libraries are not set correctly. To work around that, follow
SmokeSerpent’s instructions.


Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

Hey thanks for all the help. I’ve figured out part of my problem. It was
stupid. I had to llok at your tux typing CVS code for the kdeproj file
and compare it to mine, then finally, I looked at your header file, and
I’ve been doing include “SDL.h” instead of include <SDL/SDL.h> . Man,
that’s dumb. Anyways. I’m just trying to recompile the SDL package
without vga support, then I should be good.
Thanks for the help

YacineOn 09 May 2001 11:52:01 -0700, Samuel Hart wrote:

On Wed, 09 May 2001, you wrote:

----original----

gcc -DHAVE_CONFIG_H -I. -I. -I… -O0 -g3 -Wall -c main.c
main.c:32: SDL.h: No such file or directory
make[3]: *** [main.o] Error 1

This just looks like a bad “#include” path, go:
$ sdl-config --libs

which outputs the command line parameters to send gcc. Kdevelop is wonk,
because you can’t easily tell it to just use that or to run sdl-config as
part of your configure script, so you have to take any parameters that
start with an -L or a -l and put them in “Project Options|Linker Options|
additional libraries”. Take any other parameters and put them in “Project
Options|Linker Options|additional flags”
----end original----

Actually, sdl-config --libs outputs linker options. sdl-config --cflags
outputs the include dirs. And those must be set to something that says
include dirs or whatsoever (haven’t even seen kdevelop, can’t say
precisely), not the library thingie setting. It’s the includes that are
wrong, not the libraries. There might be some error at the linking phase
though, if the libraries are not set correctly. To work around that, follow
SmokeSerpent’s instructions.

Someone needs to go back and redo the “using SDL with KDevelop” doc, as it’s
/really/ outdated. (Not that I’m volunteering myself, or anything :wink:

Basically the problem here is likely an include one (either with #include in
the code, or with the include paths in the gcc command line.) So both of the
previous posts could be right :wink:

Without actually seeing the project, I couldn’t say specifically where it would
be. Could the original poster post their entire project as-is somewhere online
so we could look at their KDevelop configuration?

Also, on a side note, in spite of the fact that many people report problems
using SDL with KDevelop (myself included, a while ago), SDL apps can be created
and managed quite nicely in KDevelop. You just have to do a series of little
raindances to get them to play nice together :wink: Tux Typing has been managed in
KDevelop, and my newer projects (Nodin Grand, et al) will be using KDevelop as
well.

In a nutshell, here’s some of the things you need to keep in mind when making
an SDL app in KDevelop:

  1. When you create the project, unless you /really/ know what you are doing,
    just create a “Terminal C/C++” or “custom” project. This will prevent an awful
    lot of configure script headaches.

  2. In the “Project Options” dialog, under “Linker Options” be certain to see
    the additional flags setting tp “$(shell sdl-config --cflags) $(shell
    sdl-config --libs)”

  3. Enter any additional flags/libraries in “additional libraries” (for example,
    if you are using SDL_Mixer, SDL_Image, etc, add them thusly “-ISDL_mixer
    -ISDL_image … etc.”)

Currently, I think you can pretty much kiss SDL lib checking in the configure
script goodbye. This sucks, I know, but until KDevelop allows us to modify this
script ourselves (or enter additional junk for it) you are stuck. Now, you can
get around this by creating a “custom” project (allowing you to create all the
configure and makefile stuff yourself), or by changing the permissions on
configure to not allow KDevelop to monkey with it. But neither are very good
options if you are like me and have yet to figure out the intricacies of
automake/autoconf :wink:


Sam “Criswell” Hart AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

Actually, including it as “SDL.h” is the correct way to do things. Tux Typing
just has a problem there (I need to fix it, and keep forgetting :wink:

I forget why this is prefered, but off the top of my head I would guess it’s
because the library could be installed anywhere… and this also should make it
more platform independant.On Wed, 09 May 2001, you wrote:

Hey thanks for all the help. I’ve figured out part of my problem. It was
stupid. I had to llok at your tux typing CVS code for the kdeproj file
and compare it to mine, then finally, I looked at your header file, and
I’ve been doing include “SDL.h” instead of include <SDL/SDL.h> . Man,
that’s dumb. Anyways. I’m just trying to recompile the SDL package
without vga support, then I should be good.
Thanks for the help


Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >