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.
Unlike with SFML 2.x and earlier the version numbers are updated as soon
as work on the new release starts. This especially helps with version
checks, which until now caused issues with in-development version
matching the previous release.
- 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
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.
* 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
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
This commit fixes the FindXCB.cmake module for the case no components
are requested. The previous version assigned `XCB_FIND_COMPONENTS`
list to an empty variable name.
I was lucky enough to catch the bug in a corner case where both
`XCB_COMPONENTS` and `XCB_FIND_COMPONENTS` were empty and `set()`
command failed, but note this awesome CMake language supports more annoying
corner cases like `XCB_COMPONENTS` empty and `XCB_FIND_COMPONENTS`
with two elements, which results in the following `set()` invocation:
``` cmake
set(${XCB_FIND_COMPONENTS[0]} ${XCB_FIND_COMPONENTS[1]})
```
So always beware of CMake secret charms...
* Updated the Android toolchain file to support NDKs up to the latest release (r12b; based on https://github.com/gongminmin/android-cmake).
* Fixed missing sRGB extension defines - also SFML once again compiles for older target API levels not having the sRGB extensions (fixes#1079, supersedes #1085).
* Changed SFML's default STL runtime to `stlport_shared`, since `c++_shared` is no longer supported.
Environment variables (e.g. PATH on Windows) are looked up early by CMake, and libraries found there are prioritized over those in SFML's own folder. To avoid paths to wrong libraries, this commit modifies the CMake find_library() call, such that environment variables are no longer considered as suitable paths.
* 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.
* Added FindXCB.cmake script
* Added AutoPointer wrapper for automatically free'ing pointers
* Huge commit: Ported linux implementation of sfml-window to xcb
* Xcb is now used for window creation, event loop etc
* As GLX is linked to Xlib, that part of the implementation
still uses Xlib.
* Also, some keyboard related (such as XLookupString) stuff
is still Xlib, as xcb does not have it (yet?).
* Replaced some enums with the xcb equivalents
