This is what it currently looks like when find_package(SFML) fails
due to locating the incorrect library type:
CMake Error at <path>/<to>/lib/cmake/SFML/SFMLConfig.cmake:182 (message):
Requested SFML configuration (Shared) was not found
Call Stack (most recent call first):
CMakeLists.txt:7 (find_package)
CMake Error at CMakeLists.txt:7 (find_package):
Found package configuration file:
<path>/<to>/lib/cmake/SFML/SFMLConfig.cmake
but it set SFML_FOUND to FALSE so package "SFML" is considered to be NOT
FOUND.
After this change the "Requested SFML configuration" line is followed by either
Set SFML_STATIC_LIBRARIES to ON for static libraries
or
Set SFML_STATIC_LIBRARIES to OFF for shared libraries
depending on the value of SFML_STATIC_LIBRARIES. This should help clear up a
common source of confusion when users build SFML from source. The library
follows CMake convention of building static libraries by default but our
config module assumes shared libraries by default so those who build SFML
from source are prone to run into this error.
- Only fail the Mesa 3D arch check, if it's been enabled
- Add a cross-compilation CI job for Windows ARM64
- Fix ARM64 architecture detection for the Ninja generator
CMake supports a number of strings for truthy and falsey values.
ON/OFF and TRUE/FALSE are the most popular but 1/0 is also supported.
This is mostly a style choice but I'm inclined to believe that ON/OFF
is the most popular option and I'm generally in favor of style
choices that better align with the community at large.
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.
