SDL:Tutorials:Setup
From GPWiki(Redirected from C:How to set up your SDL Build Environment)
Setting up your SDL build environment can be a little tricky on some platforms, but the instructions below should help you on your way to SDL mastery. The current version of SDL can be found at the SDL download page.
[edit] Windows: MinGWSee the site [1]
MinGW and SDL: Windows Development SDL (Simple DirectMedia Layer) is a very powerful, low-level, cross-platform, high-performance multimedia library. If you are unfamiliar with this library I recommend going to the SDL website and having a look around for an hour or nine. Browse the documentation and the header files, and be sure to read the license so you know what you have the rights to use and how you may use it. Now, assuming you intend to compile SDL apps using the free MinGW compiler (MinGW?), get the latest version of the SDL from the download section on the SDL website. Get the Development Runtime for Win32, the MinGW version. SDL users tend to favour MSVC when on Windows, so some of the MinGW-specific information is a bit sparse. As-is, the development runtime package needs to be configured and installed before you can compile with it. This requires the help of a more unix-like command line shell, either Cygwin (configured to use MinGW) or MSYS from mingw.org (as described in the first section). Instead of doing this, which will install the libraries and headers into your MinGW system, I prefer to keep SDL separate so I can easily switch between versions of SDL and MinGW just by re-naming the folder. Furthermore, on Windows, you will most likely ship your app with the SDL DLLs, as opposed to compiling them statically to your app. In which case, you should take advantage of the MSVC-compiled DLL available from libsdl.org, which will in all likelyhood be better optimized than what MinGW will produce. Dynamically linking also gives the user the opportunity to upgrade the SDL DLLs themselves later if need be (or if they choose to share a single SDL.dll with all their apps by placing it in the Windows System folder). Statically linking will also tie your app to the LGPL which SDL was released under. So, to create a quick-and-dirty standalone SDL SDK which you can use with MinGW, follow these steps: Begin by unpacking the SDL development runtime archive to a temporary directory. You need to find the header files, the static-link libraries, and the SDL.dll file. These should be found (assuming the packaging hasn't changed since this writing) within another archive called i386-mingw32msvc.tar.gz that should have been created while extracting the first archive. Extract this into another temporary directory. From that you need the headers (.h) and libs (.a), including the dll. For development purposes, you might put those into a directory structure as follows: SDL/include/*.h /lib/*.a,*.dll
-lmingw32 -lSDLmain -lSDL Also, don't forget to add the -mwindows flag, if your IDE doesn't add it automatically (in addition to whatever other libraries you want to link). If you don't put them in the right order, you'll get a linker error complaining about the missing symbol WinMain@16.
MinGW and SDL_image
If you want to get up and running quickly without re-compiling from source, simply grab the runtime development package. This time however, you can use the MSVC package. You can link directly to the SDL_image.lib file as it only requires plain vanilla C linkage (no C++ or other MinGW-specific WinMain). Just extract the archive to a location and remember to set the include and lib paths when you compile. The documentation site for SDL_image is clear and straightforward. It also has an excellent example source to try which serves as a great little intro to both SDL and SDL_Image at the same time. Assuming your SDL/ and SDL_image/ directories are at the same level, create another folder at that same level, called viewimage. Grab the viewimage.c source from the demos directory, as well as a few image files to test. Put the files you download in the viewimage folder. Then you can use this makefile to build the test app: make -f viewimage.makefile MinIDE users will just build an SDL project as usual, but add the SDL_image.lib file to the project by dragging that file's icon into the target window, and adding ../SDL_image/include to the include path. Finally, copy all the .dll files (zlib.dll, jpeg.dll, libpng1.dll, SDL_image.dll and SDL.dll) to the viewimage directory so the app can find them when you run it. The app is a command-line app, so pull up a command prompt and cd to that directory. Test it by running it with the name of one of the demo images: [edit] Windows: Dev-C++
That's all you should need for basic SDL programs on windows9x/Me/2K/XP
Your build environment is now set up. To create an SDL project, perform the following steps.
If you have any difficulties setting up your Dev-C++ build environment, or if you have trouble getting your code to compile and execute, drop by our community forums and post a question. Someone will help you get things running! [edit] Windows: MSVC++ .NET
Your build environment is now set up, and VC++.NET will now know where to find the SDL and SDL_mixer headers and libraries. To create an SDL project, perform the following steps.
If you have any difficulties setting up your MSVC++ .NET build environment, or if you have trouble getting your code to compile and execute, drop by our community forums and post a question. Someone will help you get things running! [edit] MacOS X: Xcode
Your build environment is now set up. To create an SDL project, perform the following steps.
If you have any difficulties setting up your Xcode build environment, or if you have trouble getting your code to compile and execute, drop by our community forums and post a question. Someone will help you get things running! [edit] Linux: KDevelop
Your build environment is now set up. To create an SDL project, perform the following steps.
Example-macro for SDL_image: dnl Checks for libraries.
dnl Replace `main' with a function in -lSDL_image:
AC_CHECK_LIB(SDL_image,
main,
LIBS="$LIBS -lSDL_image",
AC_MSG_ERROR([*** SDL_image library not found!])
)
Another example for SDL_ttf: dnl Checks for libraries.
dnl Replace `main' with a function in -lSDL_ttf:
AC_CHECK_LIB(SDL_ttf,
main,
LIBS="$LIBS -lSDL_ttf",
AC_MSG_ERROR([*** SDL_ttf library not found!])
)
If you have any difficulties setting up your KDevelop build environment, or if you have trouble getting your code to compile and execute, drop by our community forums and post a question. Someone will help you get things running! [edit] All Platforms: GCC and G++
Your build environment is now set up. To create an SDL project, perform the following steps.
Under Linux, one can use sdl-config to determine what compiler and linker flags are required for SDL.
[edit] Mac OS X: GCC & G++You must also remember to make sure SDL_Init() is called after main() is reached within the program. Not doing so will cause seemingly random error messages to output to a console, if one is opened. To compile sources in Mac OS X using GCC/G++, you must link BOTH the SDLmain and SDL libraries, as well as setting the "framework" to "Cocoa". Examples: gcc sdl.c -lSDLmain -lSDL -framework Cocoa g++ sdl.cpp -lSDLmain -lSDL -framework Cocoa Detailed information can be found at the LibSDL FAQ Page. [edit] SConsSCons is a "software construction tool". It is a new alternative to the make tool and Makefiles. The following is a minimalistic SConstruct file that is read and parsed by SCons to build your game or application. The following example uses SDL, SDL_mixer and SDL_image for libraries, but you can add more in a similar fashion.
import glob
# create build environment
env = Environment()
# determine compiler and linker flags for SDL
env.ParseConfig('sdl-config --cflags')
env.ParseConfig('sdl-config --libs')
# gather a list of source files
SOURCES = glob.glob('*.cpp')
# add additional compiler flags
env.Append(CCFLAGS = ['-g', '-Wall'])
# add additional libraries to link against
env.Append(LIBS = ['SDL_mixer', 'SDL_image'])
# build target
# output executable will be "game"
env.Program(target = 'game', source = SOURCES)
Instead of doing a glob for all .cpp files we could list them by hand if we wanted to:
SOURCES = "column.cpp \
columns.cpp \
globals.cpp \
jewelmap.cpp \
playfield.cpp \
setup.cpp \
timer.cpp"
As you can see, the glob method is much easier, especially as we add more and more source files to our program. In the last line of the build file "env.Program(target = 'game', source = SOURCES)", the target is the name of the final executable of our program and source is the list of source files we want to build from. In the example we have a program that uses 3 libraries: SDL, SDL_mixer and SDL_image. You might be wondering why we run sdl-config to add the SDL library, but later add the SDL_mixer and SDL_image libraries to the LIBS variable. The reason is that sdl-config provides all of the compiler and link flags required by SDL, including the linker flag to include SDL as a library, but that's it. SDL_image and SDL_mixer are add-on libraries to SDL, which means they require all the same compiler and link flags as SDL, but you must also explicitly state that you are using these libraries in addition to the main SDL library. Note: SCons is "just" a utility library for Python, so you can do all the things you can in Python in SCons scripts as well. [edit] CMakeMuch like SCons, CMake is a software construction tool, alternative to the old autotools. Basic CMakeLists.txt file:
Project ( ProjectName )
set (
SOURCES
somefile.cpp
otherfile.cpp
main.cpp
}
# REQUIRED does not work in CMake <=2.4.6 for SDL
Find_Package ( SDL REQUIRED )
Find_Package ( SDL_image REQUIRED ) # if using SDL_image
# Workaround for the non-working REQUIRED flag
if ( NOT SDL_FOUND )
message ( FATAL_ERROR "SDL not found!" )
endif ( NOT SDL_FOUND )
link_libraries (
${SDL_LIBRARY}
${SDLIMAGE_LIBRARY} # if using SDL_image, obviously
SDLmain # Sadly not included in SDL_LIBRARY variable
)
add_executable (
ExecutableName
WIN32 # Only if you don't want the DOS prompt to appear in the background in Windows
MACOSX_BUNDLE
${SOURCES} # We could've listed the source files here directly instead of using a variable to store them
)
|
