You didn't think KDevelop would leave that file alone, did you? ;-)
KDevelop will recreate your configure.in file under special circumstances. The most common is when you add new directories to your project.
The best practice is to make a backup copy of your configure.in just in case you ever do anything drastic which will require a new configure.in be created. Be sure to notice the differences between the old configure.in file and the new one, since the recent changes will likely be needed. Edit a fixed configure.in that includes both the new changes, as well as the SDL items from the older configure.in.
Bear in mind that most of the time (except for the very early stages of a project) KDevelop will leave configure.in alone, so you should not need to restore it.
This is actually one place I would anticipate KDevelop will see an improvement in the coming releases, as this problem is a general one and not specific to SDL-based applications.
Yes you can! This is another strength of KDevelop, but it was something that took me over a year to figure out (I'm dense, what can I say? ;-)
configure scripts typically allow the end-user to specify the installation paths of architecture-independent files (data files) as well as architecture-dependent files (executable binaries):
configure --prefix=DATA_PREFIX --exec-prefix=BINARY_PREFIX
This is nothing new, and KDevelop's script do in fact use these prefixes. While you can choose to use the KDE File System Standard (KDE FSSTD), you do not have to and can instead rely on these prefixes.
The key to using these prefixes is to get them into your code. If you are using GCC (as most KDevelop users will be) you can pass command-line definitions using the "-D" flag. Thus, you can define a DATA_PREFIX and set it equal to whatever configure receives with "--prefix", or to the default value defined in the configure.in file in the call to the AC_PREFIX_DEFAULT(....) macro.
A very simple example is to add the following code to your configure.in file just after the last library is check, and just above the Makefile output (at the end of the file):
dnl Set up a DATA_PREFIX path for the application CXXFLAGS="$CXXFLAGS -DDATA_PREFIX=\\\"$prefix\\\""
The triple backslashes are necessary because the final line we want to pass to the compiler consists of
-DDATA_PREFIX=\"/some/path/as/defined/in/prefix\"
Now, you can just use the definition for DATA_PREFIX in your code to know that is where the data should be installed.
Note that this is nothing new, it just seems new (at least to me) in the context of using SDL with KDevelop.