SFML_ROOT can simply point to the directory in which SFML was installed.
This is verified by our install interface tests which do exactly that,
even when SFML is built as a framework. CMake can figure out where
to find the config module if you give it this much information.
The "main" component is not available everywhere, but passing it to the
find_package(SFML) call via the OPTIONAL_COMPONENTS still fails the call
on platforms like Linux.
This commit enables SFML to be used the same in a cross-platform fashion
without forcing consumers to put custom logic around importing SFML.
Example that works with this commit, but break before:
find_package(SFML REQUIRED graphics OPTIONAL_COMPONENTS main)
target_link_libraries(dummy PRIVATE SFML::graphics)
if(SFML_MAIN_FOUND)
target_link_libraries(dummy PRIVATE SFML::main)
endif()
This removes the sfml- prefixed targets from the export set. The sfml-
prefixed targets are still available within the build tree but not to
downstream users thus making this an API breaking change when compared
to the 2.x releases. To keep things consistent, usage of the sfml-
targets were replaced with their namespaced counterparts.
This has a number of benefits:
1. It's more idiomatic. Modern CMake libraries are expected to
have namespaced targets.
2. Namespaced targets are less likely to collide with user-defined
targets. No one will accidentally define a SFML:: target.
3. If a namespaced target is not found by CMake, configuration
will immediately stop.
Unlike with SFML 2.x and earlier the version numbers are updated as soon
as work on the new release starts. This especially helps with version
checks, which until now caused issues with in-development version
matching the previous release.
