SFML 2.5 CMake Migration

[eXpl0it3r]

With SFML 2.5.0 we have modernized our CMake build system largely thanks for Ceylo!
In the last weeks however we've noticed a considered amount of people not realizing the changes and thus wondering what to do with their "broken" build system. This thread should help clarify the required changes to utilize the new SFMLConfig.cmake file.

FindSFML.cmake has been removed
You can look for it as long as you want, it doesn't exist anymore, regardless of guide XYZ said, if you use SFML 2.5.0 there's no FindSFML.cmake anymore.

This also means, you no longer have to make sure that FindSFML.cmake can be found in CMAKE_MODULE_PATH. As such if you have some code like SET(CMAKE_MODULE_PATH ...) you can remove that from your CMake file.

SFML_ROOT is no more
Windows users (and maybe others) have gotten used to setting SFML_ROOT in order to tell the FindSFML.cmake where to look for SFML. This isn't true anymore and instead the error message with suggestion CMake throws at you, can finally be implemented.

Could not find a package configuration file provided by "SFML" (requested version 2.5) with any of the following names:

  SFMLConfig.cmake
  sfml-config.cmake

Add the installation prefix of "SFML" to CMAKE_PREFIX_PATH or set "SFML_DIR" to a directory containing one of the above files.  If "SFML" provides a separate development package or SDK, be sure it has been installed.

Meaning, if the SFMLConfig.cmake file can't be automatically located, you can provide the directory containing said file by setting SFML_DIR.

${SFML_LIBRARIES}, ${SFML_DEPENDENCIES} and ${SFML_INCLUDE_DIR} don't exist anymore
This is now mostly automated. The include directory no longer needs to be manually set, so this step can be completely removed. As for the libraries, all you need to specify is the dependencies on the highest level in a dependency tree. Meaning, if you want sfml-graphics, you only need to search for the graphics module and link the sfml-graphics library, CMake will take care of resolving the additionally dependencies like sfml-window or sfml-system. Even for static libraries, you don't need to specify the dependencies as CMake will do it for your.

Example CMake script

Update: Thrasher and I have put together a CMake-SFML project template, which also features quite a few useful links in the ReadMe: https://github.com/eXpl0it3r/cmake-sfml-project

Here's an example script that links sfml-graphics and sfml-audio and their dependencies.

cmake_minimum_required(VERSION 3.1)

project(SFMLTest)

## If you want to link SFML statically
# set(SFML_STATIC_LIBRARIES TRUE)

## In most cases better set in the CMake cache
# set(SFML_DIR "<sfml root prefix>/lib/cmake/SFML")

find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest sfml-graphics sfml-audio)

Documentation
A more detailed usage documentation can be found directly inside the SFMLConfig.cmake file.

While you're here, you might as well try to get your project updated to modern CMake. This article might be useful for you.

[OvermindDL1]

Been looking forward to this, however one niggle:

Code: [Select]

target_link_libraries(SFMLTest sfml-graphics sfml-audio)This is fairly non-standard, given this:

Code: [Select]

find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)Then the `target_link_libraries` line should be this to be more cmake-standard:

Code: [Select]

target_link_libraries(SFMLTest SFML::graphics SFML::audio)Following C++ stylings/conventions, components of a package are namespaced via `::`.  The first part should match the package name (same caps as well, thus all-caps in this case) and the second part should match the component name.  If there are secondary variants (like choosing a specific audio system backend or so, not relevant in this case, just an example) then that is generally done via dashes (something like `SFML::audio-pulseaudio`, though this is less standardized as more components are generally preferred, and not relevant here anyway).

[arnavb]

1. I definitely agree with OvermindDL1 in the fact that you should have use namespaced targets to go "all the way" with the modernization.

2. (This is a bit of a nitpicking) Assuming that SFML follows something like Semantic Versioning for its own versions (where major changes represent overhauls, minor changes are for additions WITHOUT BREAKING backwards compatibility, patch changes are for bugfixes, etc.), doesn't including this CMake change in a minor version break backwards compatibility? Now it seems that someone using CMake cannot simply (reasonably) try and update their code to use SFML 2.5 (Assuming they don't use the older FindSFML.cmake, which might not be compatible anymore due to the somewhat different folder structure, although I haven't tested this to make sure) without having to deal with changing the CMake code a little bit. Now obviously, this isn't a major problem, but TBH, I would have preferred a breaking change such as this one to be implemented in SFML 3.0, because then an overhaul of everything is logical.

[Sefru]

Hi!

I'm trying to use cmake to greate make files for a c++ project that uses SFML in linux (I'm using Debian). I have downloaded the SFMLConfig.cmake file linked here, placed it in /usr/share/cmake-3.0/Modules/FindSFML.cmake.

I then try to use the find_package function in my own CmakeLists.txt file as follows:
find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)

CMake finds the FindSFML.cmake script, and tries to use it, but I get an error saying that:
CMake Error at /usr/share/cmake-3.0/Modules/FindSFML.cmake:139 (message):
  Requested SFML configuration (Shared) was not found

What is the problem here and how can I fix it? Any help would be greatly apreciated. 

EDIT:
I forgot to mention, that I have installed SFML and SFML-dev packages. I can also compile SFML programs without problems when I write the makefiles manually. So in that sence everything should be ok. Now the question is just how to get it working with cmake. 

[Laurent]

CMake finds the FindSFML.cmake script, and tries to use it

If you want to use the latest changes, then this is wrong: SFMLConfig.cmake is a replacement for FindSFML.cmake. It's either one or the other; and for best results, FindSFML.cmake for versions < 2.5 and SFMLConfig.cmake for versions >= 2.5. So, the first thing to do would be to check which version the sfml-dev package installed for you.

[Jonny]

arnavb - regarding backward compatibility, FindSFML.cmake should still work, and (if found) will be used before the new config setup, so this isn't strictly a breaking change

[unlight]

Hi Guys,

I am trying to build an SFML 2.5 application using CMake in Visual Studio 2019. The CMake process is failing on the find package command with the error message shown in the attached image.

It seems that Visual Studio is having no problems locating the SFMLConfig.cmake file, but is rejecting the file because the version is not compatible. This error message remains regarless of the version number I use, or if I supply one at all.

Does anyone know what the issue might be here?

[unlight]

I figured out what my problem was and wanted to post the solution in case anyone else has the same issue. The problem was that I had downloaded the 64-bit version of SFML but VS was configured to produce a 32-bit executable. I downloaded the 32-bit version and the CMake error I described is no more.

[eXpl0it3r]

Ah right, if the architecture doesn't match, CMake won't find it.
Glad you could figure it out!

Next time, it might be better to have it in its own topic, since it's kind of unrelated to the migration instructions here.

[starach]

IDE: CLion
System: Windows 10
SFML: 3.5.1 downloaded from https://www.sfml-dev.org/files/SFML-2.5.1-windows-gcc-7.3.0-mingw-64-bit.zip

I've unzipped the package to <project>/library/frameworks/ and used the CMakeLists.txt below but got:
The following configuration files were considered but not accepted
C:/projects/sfml/./library/frameworks/SFML-2.5.1/lib/cmake/SFML/SFMLConfig.cmake, version: 2.5.1 (64bit)

cmake_minimum_required(VERSION 3.14)
project(sfml)

set(CMAKE_CXX_STANDARD 11)

# SFML
## If you want to link SFML statically
set(SFML_STATIC_LIBRARIES TRUE)

## In most cases better set in the CMake cache
set(SFML_DIR "./library/frameworks/SFML-2.5.1/lib/cmake/SFML")

find_package(SFML 2.5 COMPONENTS system window graphics network audio REQUIRED)
add_executable(sfml main.cpp)
target_link_libraries(sfml sfml-system sfml-window sfml-graphics sfml-network sfml-audio)
 

[eXpl0it3r]

You're probably using a different MinGW compiler (probably x86) and thus the architecture mismatches.

Also the SFML modules are in the wrong order in your find_package.

[satsaeid]

what's the best order of them in find_package?

[123099]

If I am not mistaken, there is no required order for them. Simply list whatever it is you need.

[prakhar9998]

https://www.sfml-dev.org/faq.php#build-link This link mentions a dependency order, maybe that's what is been referred to here.