This line was intended to silence a warning, however in the time
since that code was added in 95828a85a, the minimum required CMake
version was increased from 2.8.3 to 3.8. As of CMake 2.8.4 this
warning is no longer emitted which means we can remove this line.
Similar to sf::Time, sf::Angle provides a typesafe API for working
with angles and provides named functions for converting to and from
degrees and radians.
The SFML target export set includes a number of external targets
which are not owned by the project itself. This includes targets
like Freetype and OpenGL. By specifying a namespace for the export
set, a SFML:: namespace was prepended to all targets. This is not
a problem when using shared libraries but when building and using
static libraries caused a problem where CMake was attempting and
failing to find targets with names like SFML::Freetype or
SFML::OpenGL which did not exist.
Luckily CMake allows you put namespaces in the EXPORT_NAME target
property so now we can just add the SFML:: namespace in the macro
which creates SFML targets and remove the `NAMESPACE SFML::` line
which was adding namespaces to all targets.
This is left over from 0f83e3d but we forgot to remove it. Nothing
about this file requires an elevated minimum CMake version now that
the FetchContent usage is gone.
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.
It's not necessary to re-specify cxx_std_17 since any example or test
which depends on a core target (which should be all of them) will pick
up this language requirement that should be a public property of those
targets. If that changes, these examples and tests will possibly fail
to compile and correctly catch the bug that was introduced in the core
library targets.
