KDevelop uses aclocal, autoheader, automake and autoconf to dynamically generate and maintain the build files for each KDevelop project. These files form a very powerful and complicated suite of configuration and build tools. One of the advantages of using KDevelop is that it can shield you from having to worry about these tools, allowing you to focus on your code.
However, if you are using SDL with KDevelop, you will have to perform some minor tweaking on KDevelop's aclocal and autoconf configuration files. This will be much less exposure to the build suite then if you were not using KDevelop, so it can still be advantageous to allow KDevelop to maintain them.
In this section I will very briefly run through some of the files in this suite, what they are used for, and how to modify them. This is not intended as a comprehensive overview of auto{make|conf}. If you would like to read more about this subject, take a look at the online documentation at the FSF:
As I said, we will not be delving into the build process itself. That would be too complicated and not necessary if you plan on using KDevelop extensively.
However, it is beneficial to understand, at least superficially, the files we will be modifying and what they do.
acinclude.m4 contains macros which will be used in the configuration process. It is created from the acinclude.m4.in and libtool.m4.in files. acinlcude.m4 is rewritten each time auto{make|conf} is run.
acinclude.m4 has macros for testing compiler flags, the existence of libraries, development environments, and many other things.
acinclude.m4.in, which is used to create acinclude.m4, is a file we will modify.
configure is the master script which determines if the application can be built and how to go about building it. configure is largely created from configure.in and acinclude.m4 (though, aclocal.m4, and acconfig.h do play their roles as well). configure is rewritten each time auto{make|conf} is run.
Anyone who has compiled a few applications under Linux will have already met configure before. configure is a great tool for dynamically adjusting an application's build process to a particular system or user.
configure.in, which is used to create configure, is a file we will modify.
The Makefiles, and the Makefile.am, Makefile.in, etc which are used to create them, will be rewritten each time the configure script is run. So we do not concern ourselves with them.
Additionally, aclocal.m4, acconfig.h, and the many other build related files will either be overwritten, or will work correctly as is.
The first SDL-specific thing you will want to do in your build process is determine what version of SDL is installed, as well as what compiler and linker flags will be needed in order to use it. These items can be determined by passing the sdl-config script the following options:
sdl-config --version sdl-config --cflags sdl-config --libs
We want to modify our configure script such that it will 1) check that a minimum version of SDL is installed and 2) use the compiler and linker flags to dynamically adjust the application's Makefiles.
SDL includes in its source code tarball a file named "sdl.m4". This file is an acinclude.m4 ready file which contains the necessary macros for determining SDL's version and compiler/linker flags. The SDL Linux FAQ states that you should insert sdl.m4 into your current acinclude.m4 file, however for KDevelop applications this is not quite correct.
Recall that KDevelop uses acinclude.m4.in and libtool.m4.in to create acinclude.m4. So we need to insert sdl.m4 into acinclude.m4.in, and not acinclude.m4.
Inserting sdl.m4 is easy enough. Open up acinclude.m4.in in your favorite text editor, and insert sdl.m4 just after the first block of "dnl" comments, and before the first macro (usually "AC_DEFUN(AC_FIND_FILE, ..)").
Now that we have the macros we will need, we must write a small entry in configure.in which will access them. Looking at configure.in, near the end of the file we find something resembling the following:
dnl in this space add everything you want to check for dnl examples are specific headers, libraries, etc.
These "dnl" comments are then followed by several blank lines. This is where it is the most appropriate to check for SDL (or any other libraries).
Just after these "dnl" comments, insert the following lines:
dnl Check for SDL
SDL_VERSION=1.2.0
AM_PATH_SDL($SDL_VERSION,
:,
AC_MSG_ERROR([*** SDL version $SDL_VERSION not found!])
)
CXXFLAGS="$CXXFLAGS $SDL_CFLAGS"
LIBS="$LIBS $SDL_LIBS"
Note here that we again deviate slightly from what is reported on the SDL FAQ.
Also note that you can choose the minimum version of SDL you wish to have your application compiled against by modifying the SDL_VERSION variable.
After you have modified these files, you must regenerate your build files. While you can do this by hand, you can also let KDevelop do it for you by selecting "Build->DistClean", "Build->Automake & Autoconf" and "Build->Configure" (in that order) from your menu bar at the top of the window.
Pay special attention to the messages window. You should see no errors reported, and you should verify that the configure script now checks for a correct version of SDL.