Hardcoding this into the library itself means that outside consumers
cannot choose a different value. This in particular breaks the CMake
template project of ours which also tries to set this value.
As conventional wisdom dictates, its best to not touch CMAKE_ variables
unless necessary. Luckily our use of presents means we can easy move
this into the development preset.
My goal is to reduce our need on sfml_find_package until it can
finally be removed. It's preferred to simply use find_package to
find 3rd party projects.
I had to add IMPORTED targets to some of our find modules so that
we could get away from using INTERFACE libraries for external code.
That also implied that our find moduels need to be installed so that
users have access to them when processing SFML's config module.
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>
You cannot buy anything but a 64 bit x86 or ARM Mac today so there
is no need to ensure that one of these two architectures is being
used. It's definitely one of the two.
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
Commented out in f4c25ac3f shortly after it was added. I don't have
reason think this code will be resurrected if it's been ignored for
the last 4 years. It's safe to remove at this point.
These overrides existed to prevent MSVC errors related to duplicate
compiler warnings. Because we required a version of CMake older
3.15, CMake would add /W3 as a default compiler flag when using
MSVC. We then add /W4 in addition to that. Modern CMake versions
seem to deduplicate these warnings but older versions did not.
The easist fix is to raise the minimum CMake version to 3.15 which
changes the default behavior to no longer add /W3 without being
explicitly specified. See the below link for more information about
this behavior change.
https://cmake.org/cmake/help/latest/policy/CMP0092.html
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.