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.
Windows uses a mechanism known as 'resource files' which provides, among
other things, metadata to a given executable/dll/driver/etc, and add a
layer of polish to a project which it would otherwise lack.
vim interprets the # ex: comments as a modeline, which causes editing
this file with vim to throw an error.
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
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.
- Replaced @executable_path by @rpath for more flexibility
- Updated freetype and sndfile libs as follow:
install_name_tool -id "@rpath/../Frameworks/freetype.framework/Versions/A/freetype" freetype
install_name_tool -id "@rpath/../Frameworks/sndfile.framework/Versions/A/sndfile" sndfile
* Apparently, there were some leaks not reported as such
* Support for 32 bits computer is restored
* Fix memory leak in sfStringToNSString (related to #484)
* Unapply context when closing the window, freeing memory
The following commits are related to ARC modifications:
* 42f6e83dfb
* 6edc4b9518
* f6c94451fb
* 324d4a18e7
* 0d47056132
Commit ac28902b57 is the last one before the introduction of ARC.
A current limitation prevents one library from depending on shared libraries.
As we have legal issues here (LGPL wants us to use shared libs of OpenAL-Soft and libsndfile), we're forced to use this homemade native activity which will manually load our shared libraries.
