The name of the find module was changed to match the name used by
the reference implementation of Vorbis. Likely the target names were
taken from what the reference implementation names those targets.
All in service of hopefully removing sfml_find_package one day since
that will simplify packaging SFML and better set us up for adopting
a package manager.
In a few places I left references to the old name where appropriate.
There are also many CMake references to "OSX" that we have to keep
using since CMake does not offer alternative names for those variables
and target properties.
* Use built-in iOS support for cmake and expand tests to cover more configurations
* Adjust CI builds
* Update examples version
---------
Co-authored-by: Chris Thrasher <chrisjthrasher@gmail.com>
libc++ is already the default and GCC can't even be used so there's
no circumstance where we'd need to explicitly tell Clang to use
libc++. I confirmed that even with this removed, libc++ headers are
still being used and found.
Using a newer CMake version allows us to make use of the
MSVC_RUNTIME_LIBRARY added in CMake 3.15, which handles static linking
of the runtime library with MSVC a lot simpler
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 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.
Windows uses a mechanism known as 'resource files' which provides, among
other things, metadata to a given executable/dll/driver/etc, and add a
layer of polish to a project which it would otherwise lack.
