While you can't easily run these unit tests, it's easy enough to
still compile them so we don't need to go out of way to prohibit
this. CMake has some support for running tests on the target OS
so perhaps in the future we find a compelling way to run the test
suite on a mobile OS.
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.
This is not the best default value because it imposes additional
requirements on user builds that are not strictly necessary. This
has caused many complaints in the past as people encounter build
failures that are merely due to warnings and not hard compiler
errors.
Changing this default value emakes it more likely that someone trying
to use SFML can use it without issue.
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.
This is a lighitly modified copy of CMake 3.27.4's FindOpenAL.cmake
module. This gives us access to the OpenAL::OpenAL target which was
not added until CMake 3.25.
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.
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.
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.
