* 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.
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
Ported sfml-pi DRM/KMS backend written by @mickelson
Port co-authored by @substring
Co-authored-by: Andrew Mickelson <andrew.mickelson@gmail.com>
Co-authored-by: Gil Delescluse <frog2wah@gmail.com>
The "main" component is not available everywhere, but passing it to the
find_package(SFML) call via the OPTIONAL_COMPONENTS still fails the call
on platforms like Linux.
This commit enables SFML to be used the same in a cross-platform fashion
without forcing consumers to put custom logic around importing SFML.
Example that works with this commit, but break before:
find_package(SFML REQUIRED graphics OPTIONAL_COMPONENTS main)
target_link_libraries(dummy PRIVATE SFML::graphics)
if(SFML_MAIN_FOUND)
target_link_libraries(dummy PRIVATE SFML::main)
endif()
The SFML target export set includes a number of external targets
which are not owned by the project itself. This includes targets
like Freetype and OpenGL. By specifying a namespace for the export
set, a SFML:: namespace was prepended to all targets. This is not
a problem when using shared libraries but when building and using
static libraries caused a problem where CMake was attempting and
failing to find targets with names like SFML::Freetype or
SFML::OpenGL which did not exist.
Luckily CMake allows you put namespaces in the EXPORT_NAME target
property so now we can just add the SFML:: namespace in the macro
which creates SFML targets and remove the `NAMESPACE SFML::` line
which was adding namespaces to all targets.
This removes the sfml- prefixed targets from the export set. The sfml-
prefixed targets are still available within the build tree but not to
downstream users thus making this an API breaking change when compared
to the 2.x releases. To keep things consistent, usage of the sfml-
targets were replaced with their namespaced counterparts.
This has a number of benefits:
1. It's more idiomatic. Modern CMake libraries are expected to
have namespaced targets.
2. Namespaced targets are less likely to collide with user-defined
targets. No one will accidentally define a SFML:: target.
3. If a namespaced target is not found by CMake, configuration
will immediately stop.
It's not necessary to re-specify cxx_std_17 since any example or test
which depends on a core target (which should be all of them) will pick
up this language requirement that should be a public property of those
targets. If that changes, these examples and tests will possibly fail
to compile and correctly catch the bug that was introduced in the core
library targets.
