SDL, the Simple DirectMedia Layer, is a thin, cross-platform multimedia library. At the time of this writing, it is probably the most popular multimedia library in use under the various Nixes for Open-Source and Free-Software projects. It also powers every one of Loki Entertainment's commercial Linux game ports.
KDevelop is an Integrated Development Environment (IDE) designed around the K Desktop Environment. Many developers find that it is a complete and intuitive development environment with an abundance of features. It can manage documentation (working with external SGML tools), integrate with RCS or CVS, assist in debugging, and help create and maintain a project's build process.
Unfortunately, as a quick search on either the KDevelop or SDL mailing lists will show, SDL and KDevelop do not inherently work well together.
Any SDL programmer who wants to use KDevelop to help manage their projects.
I will admit that this document is also intended more towards the auto{make|conf} uninitiated, since those who already have mountains of experience in this area will likely have already figured out how to solve the problems between SDL and KDevelop (indeed, to such people these problems might not seem like problems at all).
Basically, I am writing a document that I would have loved to have had when I first got into SDL and KDevelop a couple of years back ;-)
At the time of this writing, the most recent stable versions of SDL and KDevelop are 1.2.1 and 1.4, respectively. While some of the issues and problems I address in this documents may be resolved with future versions of either, I doubt they all will be.
KDevelop is still largely geared towards two groups: 1) KDE and potential-KDE developers. 2) Pseudo-newbies who don't understand the auto{make|conf} process or lazy-gurus who don't want to deal with the auto{make|conf} process (I must admit that I lie somewhere between pseudo-newbies and lazy-guru).
Because of these motivations, it is unlikely that KDevelop will adopt a build policy which will address the intricacies of creating "proper" (platform independent) SDL applications. This is not a short-coming of KDevelop at all, since KDevelop is intended for more general Linux/Unix use, but it can make KDevelop less-than friendly towards platform independent APIs.
Technically, you can use the default KDevelop generated build files in an SDL application. However, in order to utilize them, you will have to use SDL in a very dangerous way.
First, you will have to include the SDL header files directly from where ever they are on your system. As an example, on my system they are installed in /usr/include/SDL, and I would have to include the SDL headers thusly:
#include <SDL/SDL.h>
In addition to this, you would have to inform KDevelop where the SDL libraries are specifically. Again, on my computer they have been installed into /usr/lib/SDL, so I would have to include a '-lSDL -L/usr/lib/SDL' in my extra options in the KDevelop "Linker Options" screen.
Finally, you would have to list those extra libraries which SDL used on your particular platform. My platform is Linux, and under Linux SDL uses the pthreads library.
While creating an SDL application this way will work correctly on your system, there is no guarantee that your application will build on other systems (whether they are running the same OS as you or not).
The SDL header files and libraries could easily be installed on another path. For example, some Unix users prefer to install libraries like this under /usr/local or /opt. Plus, on Win32 or MacOS platforms you can't assume these libraries will be in any particular location.
Any extra libraries you included may also cause problems. The libpthread that SDL needs under Linux is unavailable under BeOS.
So by using the default KDevelop build files, you will be preventing your application from building on many OSes. You may also prevent your application from building on similar OSes to yours, but with alternative SDL installs.
The most portable way to utilize SDL in your application is to include "SDL.h":
#include "SDL.h"
In order to include the SDL header file this way, your compiler must know where your SDL header files are located. Also, your linker will need to know the path to the SDL library files, as well as any other libraries SDL needs on your platform.
SDL provides a script called "sdl-config" which supplies this information. You can be guaranteed that calling sdl-config will return the correct flags for whatever system your application is being built upon.
Using sdl-config is actually a very liberating experience. No longer do you need to keep track of where your SDL libraries are installed, what flags they might need from the compiler, or what other libraries SDL depends on.
For more information on the "Standard" SDL build process, take a look at the following links.
http://www.libsdl.org/faq/FAQ-General.html#GENERAL_INCLUDE
http://www.libsdl.org/faq/FAQ-Linux.html#LINUX_2
http://www.libsdl.org/faq/FAQ-BeOS.html#BEOS_2
http://www.libsdl.org/faq/FAQ-Win32.html#WIN32_8
Typically, the way you start a new SDL project in KDevelop is through the Application Wizard. Click on "Project->New" from the pull down menus, and you will be presented with the wizard.
Unless you want to use Qt or the KDE libs, you will want to just start a Terminal->C, Terminal->C++ or a Custom Project.
A Terminal->C or Terminal->C++ project will create the directory structure for your project, generate the default build files (unless you tell it not to), generate the default documentation, and create a simple "Hello World" application in either C or C++. A Custom Project will create an empty project.
This mini-HOWTO assumes that you have created either a Terminal->C or a Terminal->C++ project, and that KDevelop is managing your build files. If you create a Custom Project, then this mini-HOWTO might not be very useful to you.