Building SFML 2.0

Note: this tutorial is deprecated. Please take a look at one of my new ones, either for Visual C++/NMake (Windows), MinGW (Windows) or GCC/Make (Ubuntu/other Unix).

To set up SFML 2.0, there are a number of steps. If you want, you can watch SFML 2.0 build video for Code::Blocks, or for Visual Studio.

Otherwise, I shall outline the necessary steps here, before providing a few more details where necessary.

1. Download CMake from the website, or go straight to the download page.
2. Download the SFML 2.0 source, unzip the file, move it to an accessible location and rename the folder.
3. Create a solution file for your IDE using CMake, setting BUILD_SHARED_LIBS to TRUE.
4. Take note of the value of STATIC_STD_LIBS, as you must link the C runtime to your project in the same manner as it is linked to the SFML binaries
5. Open the solution file in your IDE and build SFML 2.0 in Debug and Release configuration (if your IDE supports multiple configurations).
6. Repeat steps 3 & 4, with BUILD_SHARED_LIBS set to false.
7. If your IDE does not support multiple configurations, repeat steps 3 – 5, setting.
8. Copy and paste the resulting libraries to a better location: put them all in a lib subdirectory of your main SFML 2 directory: c:/sfml/sfml2.
   

1. Downloading CMake

This step isn’t hard. Just follow my link to the download page and select the version that is right for your OS!

2. Downloading SFML 2.0

Downloading SFML 2.0 should be easy enough. I shall just point out that the downloaded file is a .tar.gz file so you must extract it using software like 7-Zip, and then extract the resulting file. At last you get a folder with an obscure name which you should rename to something more manageable such as sfml2. Finally, copy it to a more suitable location on your hard drive, such as c:/sfml.

3. Creating a solution file using CMake

Once you have downloaded and installed CMake, you should open the GUI version and enter the directory c:/sfml/sfml2 (or whatever you chose) as your source file directory and c:/sfml/sfml2/build/ as your binaries directory.

 Next, you should click the configure button and select your generator. The generator is simply the IDE/compiler you are using. For Code::Blocks with MinGW, choose (you guessed it!) Code::Blocks with MinGW. For Visual C++ 2010, choose Visual Studio 10, for 2008 choose Visual Studio 9 and for 2005 choose Visual Studio 8. If you want help working out which generator to pick, feel free to ask!

CMake will configure for a while and when at last it is done, you are presented with some options highlighted in red. One is called BUILD_SHARED_LIBS. Check this (i.e. set it to TRUE), so that building the resulting solution file will yield the dynamic libraries.

The is one other important option: CMAKE_BUILD_TYPE. This defines which configuration we get – debug or release. (If you didn’t know, a configuration is just a set of options for the build; debug configuration results in binaries with debug information, release configuration results in binaries without it).

An additional option to consider is STATIC_STD_LIBS. If this is set to TRUE, the C runtime will be linked to the binaries statically; otherwise it will be linked dynamically. This isn’t too important, but you must ensure that your project links to the C runtime in the same way. The Visual Studio video has instructions to this effect in the notes section, but I’m not aware of people having such problems with other IDEs/compilers. If you do, let me know!

If you have an IDE such as Visual Studio which supports multiple configurations, you need not worry about this option. Otherwise, set it to Debug.

Now we have set all the options we wish to set. Click the Generate button to generate the solution files.

4. Building SFML 2.0

Now if you go to your c:/sfml/sfml2/build/ directory, you should find a solution/project file for the IDE you chose. Open it and build it by choosing your IDE’s build all/build solution/build workspace option. If your IDE supports multiple configurations, you can build with debug configuration and then again with release configuration from the same project.

5. Building SFML 2.0

Now return to CMake and repeat steps 3 & 4, this time with BUILD_SHARED_LIBS set to FALSE.

6. Debug and Release Configurations

If your IDE supports multiple configurations, and you have already build libraries for debug and release configurations (in both the static and dynamic case). Otherwise repeat steps 3 – 5 with CMAKE_BUILD_TYPE set to Release.

7. Relocating the binaries

By this stage, depending on which IDE you have been using, you will have SFML binaries scattered through a number of directories. They will most likely all be in directories within your build subdirectory or in a lib subdirectory of the main SFML 2.o directory.

Now, I recommend you copy all of these libraries to the lib subdirectory of the main SFML 2.0 directory. Just to help you find them, they should have extensions .lib, .a, .dll (on a non Windows OS, shared libraries will probably have a different extension) and .pdb (program debug database – debug files created by Visual Studio).

If there are any other files in the same directory, then I recommend you copy them over too, just in case!

8. Final Comments

You are now all done – you should have all the SFML 2.0 binaries you could possibly imagine inside your lib subdirectory. There are just too last points I would like to make.

A. SFML Binary Filenames

You may notice that the SFML binaries for debug configuration have a -d on the end of their name, whereas the release ones do not. Similarly, the static ones have a -s and the dynamic ones do not. Consequently the static debug libraries have -s-d at the end!

B. Import Libraries

You might also have noticed that even when we built the dynamic libraries, we got .lib or .a files. Well if you check, you will see that these libraries are very small – much smaller than the actual static .lib/.a files from the actual static configuration. These are called import libraries and basically, we link to them to give us easy access to the dynamic libraries – there is thus no need for us to manually load the dynamic libraries into memory ourselves. While they have the same file extension as static libraries, they are not the same thing!

Well that’s all for this lesson – I hope it helps. I’ll see you next time when we write a minimal SFML 2.0 application.