- 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
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>
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.
- On Windows you can use Clang with both MSVC and MinGW
- When using Clang with MSVC all the MSVC conditions should be fulfilled
- When using Clang with MinGW all the MSVC steps should not be run
* Removed duplicated CMake code
* Made it possible to manually specify the pkg-config path
* Install pkg-config files by default on Linux and BSD systems
This commit drops the previous custom CMake toolchain file for Android
in favor of CMake's new built-in toolchain for this (CMake >3.7.2).
This makes building SFML for Android a lot simpler and more straight
forward, working almost as smooth as other platforms.
To configure your build directory, all you have to do is defining just a
few variables the first time you invoke CMake.
**Required Variables**
* `CMAKE_SYSTEM_NAME` must be `Android`, so CMake knows we actually want
to cross-compile.
* `CMAKE_ANDROID_NDK` must point to the NDK's installation directory,
e.g. `/usr/android/ndk` or `c:/android/ndk`.
**Recommended Variables**
* `CMAKE_ANDROID_STL_TYPE` defines the STL implementation to be used.
You should use `c++_shared`, although others might work.
**Optional Variables**
* `CMAKE_SYSTEM_VERSION` can be set to pick a specific SDK version other
than the latest.
* `CMAKE_ANDROID_ARCH_ABI` defines the target architecture and ABI, for
example `armeabi` or `armeabi-v7a`.
Based on your system, you might want to enforce a specific generator to
prevent issues, e.g. using `MinGW Makefiles`.
This grew out of my work creating an sfml port for macports, but should
be helpful for package maintainers of various distributions:
* add an SFML_USE_SYSTEM_DEPS option to ignore everything in extlibs/
except for headers/stb_image, and use the system versions
* install pkg-config files if a pkg-config program is found
and either lib/pkgconfig or libdata/pkgconfig exists under the
INSTALL_PREFIX, or the SFML_INSTALL_PKGCONFIG_FILES flag is set
explicitly
* install pkg-config files for static libs too, add the necessary
Requires.private and Libs.private entries to the .pc files to support
static linking
* on OS X, honor all INSTALL_NAME and RPATH related cmake variables and
only set the INSTALL_NAME_DIR to "@rpath" if none of them is set, this
preserves the default behavior of using @rpath but also allows
overriding by the usual cmake mechanisms
* Replaced the toolchain file with a new version based on [zuhowei's fork](https://github.com/zhuowei/android-cmake), which enables x64 builds as well as support for the latest NDK. This breaks compatibility with old build directories.
* Removed the STL dependency from **sfml-activity** rather than relying on *some* implementation implicitly linked by default.
* Deleted *project.properties*, which wasn't supposed to be part of the repository code. You have to use the Android SDK to recreate it (`android update project --path to/your/example --target 1 --name SFML-Example`).
* Made it possible to select a STL implementation to be used (default: `c++_shared`). Keep in mind that not all available configurations are necessarily compatible with SFML.
* Fixed linker flags to be compatible with Nvidia's Nsight Tegra for Visual Studio.
* It is now possible to compile the Android version using Nvidia's Nsight Tegra for Visual Studio (requires up-to-date CMake and `CMAKE_SFML_SYSTEM` to be set to `Android`; keep in mind that this is still experimental and requires further CMake updates).
* Updated and renamed some Android specific CMake variables.
* Made `armeabi-v7a` the default ABI for Android builds.
What's new in the templates:
- Removed support for 32 bits and gcc
- Removed useless code
- Removed custom warnings settings – let Xcode decide with its default values
- Set default target version to CMAKE_OSX_DEPLOYMENT_TARGET
What's new in cmake script:
- Added cmake options for archs and deployment target
- Added minimum requirements checking