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.
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.
A core tenet of CMake is the idea that you can use any valid C++
compiler. By enumerating all supported compilers and emitting and
hard error when an unrecognized compiler is detected, we are violating
that tenet.
Relaxing this message from a fatal error to merely a warning continues
to communicate to users that their build may not succeed but it leaves
the door open for the build to potential succeed if the compiler meets
all of our requirements.
* 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>
This is required since Windows can't support she-bang scripts like
macOS and Linux were taking advantange of. This is more verbose but
ultimately the same as before.
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
There is no need to check for macOS 10.6 or lower. Snow Leopard came
out in 2009. Because it's nearly 13 years old, it's safe to say
nobody will be trying to build SFML 3 on Snow Leopard.
This was added in de70f691e way back in 2011 when Snow Leopard was
a mere cub.
The use of target_compile_options makes it easy to append warnings
to a target. The use of generator expressions also more succinctly
handles a few edge cases for compiler bugs and platform-specific
oddities.
This should be easy to read and maintain than the variable-based
solution it replaces.
