mirror of
https://github.com/SFML/SFML.git
synced 2024-12-01 15:51:04 +08:00
4586db91a9
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.
|
||
|---|---|---|
| .. | ||
| resources | ||
| CMakeLists.txt | ||
| CocoaAppDelegate.h | ||
| CocoaAppDelegate.mm | ||
| main.m | ||
| MainMenu.xib | ||
| NSString+stdstring.h | ||
| NSString+stdstring.mm | ||
| readme.txt | ||
SFML IN COCOA APPLICATION ========================= This is a small example of the integration of SFML in a Cocoa application. Features -------- * This example shows how basic UI elements can interact with SFML render areas such as sf::RenderWindow (you can use sf::Window and OpenGL code too, of course). * It also provides tools for converting NSString to and from std::[w]string in an Objective-C Category of NSString. * Moreover, it shows how you can prevent annoying the system alerts produced when the SFML view has focus and the user press a key (see SilentWindow interface in CocoaAppDelegate.[h|mm]). Special Considerations ---------------------- While mixing SFML into a Cocoa application you have to deal with mixing C++ and Objective-C. In order to proceed you should use .mm extension for Objective-C++ files. Be aware of the limitations of Objective-C++. Please refer to the official documentation provided by Apple for more information. You can also work around these limitations by using CSFML.