Compiler warnings are a tool we enable as developers to detect
issues with our source code that go beyond the basic requirements
of compiling C++ code. For example, many implicit conversions are
perfectly correct, and defined behavior in C++ but we choose to
disallow them with -Wconversion. This is something only us devs
have to care about. Someone using SFML wants the library to work
well but does not need to concern themselves with such low level
details about its implementation.
By disabling warnings in non-developer builds, we ensure that non-
developer users of SFML are not going to see console noise due to
warnings and it prevents issues like GCC's bug 82952 which causes
compilation to halt indefitely due to a bug in how a compiler
warning is implemented.
This also improves compatibility with older compilers. If we enable
warnings in all builds no matter what, we have to protect against
compilers we don't expect. Perhaps someone uses an older version
of GCC that we haven't tested with. This compiler is perfectly fine
compiling our C++ but we happen to use a warning flag it does not
recognize so the build fails. This is not a good reason for a
build to fail but nevertheless it's something we have to deal with
so long as we always enable warnings.
SFML_WARNINGS_AS_ERRORS is now named somewhat incorrectly but I
retained the name for compatibility's sake. We can rename it to
SFML_ENABLE_WARNINGS or something similar in SFML 4.
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.
