This is what it currently looks like when find_package(SFML) fails
due to locating the incorrect library type:
CMake Error at <path>/<to>/lib/cmake/SFML/SFMLConfig.cmake:182 (message):
Requested SFML configuration (Shared) was not found
Call Stack (most recent call first):
CMakeLists.txt:7 (find_package)
CMake Error at CMakeLists.txt:7 (find_package):
Found package configuration file:
<path>/<to>/lib/cmake/SFML/SFMLConfig.cmake
but it set SFML_FOUND to FALSE so package "SFML" is considered to be NOT
FOUND.
After this change the "Requested SFML configuration" line is followed by either
Set SFML_STATIC_LIBRARIES to ON for static libraries
or
Set SFML_STATIC_LIBRARIES to OFF for shared libraries
depending on the value of SFML_STATIC_LIBRARIES. This should help clear up a
common source of confusion when users build SFML from source. The library
follows CMake convention of building static libraries by default but our
config module assumes shared libraries by default so those who build SFML
from source are prone to run into this error.
In the `ov_read` API, the fouth parameter says what endianness the
samples should be returned in - `0` for little-endian, and `1` for
big-endian. SFML wants samples in the host endian, so we need to set
this parameter to 1 on big-endian systems.
Fixes a unit test failure on big-endian systems.
If `XOpenIM` fails we will store a `nullptr` into `sharedXIM`. When
the shared `XIM` is destroyed we call the deleter `XCloseIM` on the
`nullptr` which segfaults.
Fix this by adding a new `closeIM` helper function which checks for
null first.
If `XInternAtom` is called with `onlyIfExists` set, then it can
legitimately return `None`. We should not cache this value because it
might change in the future.
This bug can sometimes be triggered because we use
`getAtom("UTF8_STRING", true)` and `getAtom("UTF8_STRING")`. If the
first call caches `None` because the atom didn't exist, then the
second call could return `None` instead of creating a new atom like it
should.
In 248fd6d we added a lot of 3rd party C source files. That means
building SFML has the additional requirement of needing a C compiler.
I would expect that all of this would be properly handled by those
upstream projects properly telling CMake to find a C compiler but
apparently that is not the case.
By removing `LANGUAGES CXX` we are telling CMake to fall back to its
default behavior to find a C and C++ compiler.
These are estimates. We don't necessarily have access to all prior
compiler releases and don't continuously test with these old
compilers so it's possible that we accidentally drop support in a
future v3 release even without raising the minimum C++ requirement.
This reverts commit 46a1b568a9 as it seems
to cause wrong reporting on pull request coverage info, likely due to
missing baselines from the master branch "push".
- Actually use the dimensions of the SFML window as the DRM mode
dimensions when setting a DRM mode.
- If SFML window dimensions don't match a valid DRM mode, show
the window contents on screen in the current mode instead of
simply failing to show anything.
- With these change the SFML examples are now working for me
